Platforum\Compass\Requirements & Scenarios\Smart Transportation
Building blocks for smart transportation shall allow the designer of a smart transportation system to make use of existing, pre-designed parts of the system in the design of their system. We provide various scenarios at different levels of the system.
Transportation Scenario A: Supplier independence in automotive/plane design (vertical)
Consider the scenario where an automotive or aeronautics OEM wants to design a car/plane. While the OEM designs the entire system, subsystems are delegated to suppliers. For instance, the brake mechanism or the movement of a flap. Such subsystems have many commonalities from one car/plane to another, and are therefore good candidates for building blocks.
Such a subsystem is a CPS because it includes the development of both mechanical parts (e.g., screw jack to move the flap, linear variable differential transformer to measure the opening of the screw) as well as the software controlling these parts (e.g., for the deployment of a flap: the voting system for input values coming from sensors, the “freshness” monitor).
Furthermore, it is worthwhile providing such subsystems as building blocks since it allows the OEM to make abstraction of this part in a “standardized” manner: having a generic description of, say a “brake system” building block or an “flap control” building block would allow them to be independent of the supplier by:
- Allowing to switch from one supplier to another more easily,
- Making the tendering phase definition faster,
- Making the design of the system faster by having a set of building blocks available.
From the OEM perspective, such building blocks are essentially characterized by their requirements, defining the purpose that the building block shall fulfill.
Societal/Human: OEM System Engineers, OEM Purchase department, Supplier Sales department
Process: Interactions between OEM and suppliers are simplified and made more formal. Possible partial automation (automatic search in a “market place” for building blocks).
Information: Data at the interface of building blocks carries requirements in a more formalized (or at least standardized) manner.
Technology: Interface shall be technology-independent when it does not matter (the OEM does not need to know the technology implementation details of the supplier, which can contain supplier intellectual property), and technology-exposing when it matters (a building block might be dependent on a specific technology used at the higher level, e.g. communication protocol). The FMI standard should play a key technological role here.
Transportation Scenario B: OEM independence in automotive/plane design (vertical)
Consider the same scenario as scenario A but from a supplier’s perspective. Having their product specified as a building block provides a risk since OEMs can change suppliers more easily. However, it also is an opportunity, since the market of suppliers is extended to all potential OEMs following the building blocks principle: a supplier, who used to work with only one OEM, can now work more easily with other OEMs and thus extend their set of customers.
It also allows cost saving, particularly in domains where certification plays an essential role like avionics. For instance, the building block for a safety-critical subsystem (like flap control) could contain not only the software, but also the certification artifacts (e.g., software development plan), the verification artifacts (e.g., test reports) as well as the traces between the design and these artifacts.
Of course, such a building block can generally not be reused “as-is” but needs to be parametrizable: for instance, the screw controlling a flap has most probably different lengths from one plane to another. Even more complex, a block can itself refer to other building blocks of lower or higher level. For instance, even if the architecture of the control of a flap can be very similar from one plane to another, the control laws governing it depend in an essential manner on the shape of the entire plane.
Societal/Human: Supplier Sales department, supplier engineering (to factorize effort among various designs).
Process: Interactions between sales and engineering are simplified and made more formal, since the same “language” is used among projects.
Information: Data shall carry more information than just the requirements: as mentioned, verification, certification or traceability artefacts can be delivered additionally.
Technology: The supplier, depending on the OEM needs, can expose relevant technology information.
Transportation Scenario C: Inter-vehicle communication (horizontal).
The two previous scenarios deal with building blocks at design time. Building blocks can however be considered at runtime as well. Consider inter-vehicle communication as an enabler for smart mobility: the considered CPS is not anymore one vehicle but an assembly thereof; every vehicle becomes a building block of this assembly. Every vehicle must provide not only its location, communication protocol and, say, target destination (information), but on its pose, its geometry, its kinematics (physics). This scenario thus also considers the vehicle as a CPS building block.
The “openness” of this scenario highlights the need for security considerations: building blocks shall be interoperable but not leak too much information. In particular, considering the safety-critical aspect of mobility, the high interaction between security and safety shall be considered. This highlights the needs as well in terms of certification: the building blocks shall probably allow “on-the-fly” certification of the assembly of vehicles or of each of its components. This entails further that the building blocks shall communicate information, which is usually to be provided only at design time, e.g., requirements, usage limits, verification artefacts.
Societal/Human: Law makers, standardization authorities, OEM representatives, infrastructure actors (public as well as private).
Process: Easier integration of new players (since the requirements on vehicles are standardized as building blocks), new process for existing players (comes with the new model: there was of course no need to align with authorities when there was no inter-vehicle communication).
Information: Information at both, the cyber- as well as physical- level, shall be provided. Only relevant information on pose, location, target destination, available sensors, etc. shall be communicated for connectivity and security reasons, following well-known basics of security (encryption, etc.).
Technology: Key technologies here shall be 5G for inter-vehicle communication and data fusion for interpretation of all the data provided by the various vehicles.
Back to Requirements & Scenarios
Your feedback is welcome!
We invite you to give your appreciated feedback on the presented results here.
If you cannot login to the Platforum, please contact us for help.