The Sandbox: the AVSandbox knowledge hub

 

The Future of transport system is an increasingly complex system of systems (SoS) involving the management of information exchanges between a wide range of disparate systems of systems involving vehicles, traffic management and monitoring, infrastructure, communication, journey planning systems, security systems and of course people (travellers and pedestrians), in different operational scenarios, corresponding to different levels of criticality.

“System of systems or SoS is a collection of systems that pool their resources and capabilities together to create a new, more complex system which offers more functionality and performance than simply the sum of the constituent systems.”

As the demand for more efficient transport increases there is an urgent need to manage the evolution of the system architectures associated with future transport systems. Therefore, we need to:

• Have a long-term architectural strategy, which is driven by current needs rather than legacy
• Have a global framework regarding vehicle automation
• Understand the transfer of control between the vehicle and the driver and vice versa
• Fully define and model the behaviour of automated vehicles in relation to other road users
• Identify how to communicate the system reliability information to the drivers
• Able to evolve and be resilient

Approach to creating a Reference Architecture

A reference architecture is a term usually used in creation of complex Systems which provide a template solution for an architecture for a particular domain such as common vocabulary, architectural vision.

It is an evolutionary architecture supporting legacy and future needs of intelligent transport systems.

Reference architecture in such system has as purpose to:

• Identify a framework for integrating connected vehicle technologies
• Identify interfaces that are candidates for standardisation.

A reference architecture will provide a strategy for ensuring that there are sufficient standards to support implementation and ensure interoperability in its different views consisting of:

• The Enterprise view describes the relationships between organizations and the roles those organizations play within the connected vehicle environment.
• The Functional View addresses the analysis of abstract functional elements and their logical interactions.
• The Physical view describes the connections between Physical Objects within the connected vehicle environment.
• The Communications View describes the communications protocols necessary to provide interoperability between Physical Objects in the Physical View.

As autonomous and connected vehicle applications continue to evolve at various levels, we need to be a framework from which potential interfaces & candidates for standardisation can be identified and analysed using Model Based System Engineering. The latter is a formalised application of modelling to support system requirements, design, analysis including behavioural analysis, system architecture, requirements, trace-ability, performance, simulation and test.

The first step is to analyse and represent the system’s users, their operational needs, and the usage scenarios. Who are the actors involved in interacting with the system? Actors can be human users as well as other entities involved in autonomous driving like other road users, road infrastructure like traffic lights, etc.

Once the actors are defined, the next task is to determine what they want the system to do.

• What behaviour and services do they expect from the system?
• What are the contexts within which the actors will interact with the system?
• What will be the modes of interaction, and how are they related to the operational contexts?

Depending on the modelling languages and tools used, there are varieties of diagrams, process definitions, allocation of actors to process artifacts for capturing and representing the system:

•  From identifying concepts of operations and requirements expected from the system and its usage by the actors involved.
• To identifying the main system components, their contents, relationships, hierarchies, properties, and behaviour which constitutes the logical or functional architecture of the system and it excludes concerns related to technological implementation of the identified components.
•  To modelling and grouping of application software components within the system.
• To modelling of the platforms on which the application software components execute.

Numerous tools such as IBM Rhapsody, AnyLogic, Dassault Cameo, Magic Draw and others can be used to model and architect such systems and see the interaction with their different subsystems to which will be diving in other blog posts.

Written by Amina Hamoud – Project Engineer

Please get in touch if you have any questions or have got a topic in mind that you would like us to write about. You can submit your questions / topics via: Tech Blog Questions / Topic Suggestion