Model-Driven Engineering of Infotainment Networks
An infotainment network is a network designed to transfer data, audio and video content between the embedded systems of the infotainment system. A node is an embedded system that is connected to the infotainment network. The node has at least one network interface controller to communicate with other nodes through the network.
The design complexity of an infotainment network is a challenging task. The ability to perform the duty of creating, maintaining and modifying the design of an infotainment network must be supported by computer science knowledge (software and hardware engineering, general and specific technologies and platforms etc.) and non-technical knowledge (for example, industry’s best practices, project management and knowledge of most relevant domains) and organizational and communication skills. The system that implements the designed infotainment network must be aligned with business requirements and the overall costs of the design and development must be acceptable.
A model that specifies an infotainment network at a high level of abstraction paves the way to overcome the complexity of the design. Model-driven engineering (MDE) is the well-known methodology used to create and exploit domain models as a basis to implement specified systems. A set of models introduces the unified terminology to promote communication between the project participants, such as business analysts, system designers and domain experts. The models also help to increase productivity by reusing design patterns and applying best practices.
The models encapsulate technical aspects of the underlying technology and represent an initial abstraction view. Furthermore, those models can be used as input data for automation tools to simplify subsequent activities of the software development process, such as prototyping and simulation, implementation and testing etc.
The Unified Modeling Language (UML) is the widespread standard used to model various systems. UML supports a generic extension mechanism for building domain-specific models, called UML profiles. UML is one of the key standards related to model-driven architecture (MDA™). MDA is the approach to implement MDE, as provided by the Object Management Group (OMG).
MDA specifies three default models of a system: Computation Independent Model (CIM), Platform Independent Model (PIM) and Platform Specific Model (PSM). A CIM is a business or domain model that defines exactly what the system is expected to do. A PIM is an abstract model used to create a Platform Specific Model (PSM), which in turn is a model of the concrete system that implements the PIM upon the specific technology.
For larger image click here
MDA has the capability to define transformations that map the models. A transformation from CIM to PIM is technically possible, but the efficiency of such a transformation is questionable, because CIM contains no technical details and may include informal requirements. Nevertheless, the CIM requirements should be traceable through the PIM to the PSM constructs. The PIM, which abstracts out the technical aspects, may be effectively transformed into several platform-specific models.
The design of an infotainment network specifies, among other things, the physical deployment of software components on nodes, the inter-communication protocol (data exchange) between those components, and a configuration of bandwidth allocations to transfer data, audio and video contents between nodes (connection management). It is essential to note, that each node cannot be considered as an isolated device, but must be designed as part of an infotainment network. The UML deployment diagram depicts a physical deployment of the software components on nodes and can be used as specified in the UML standard. An UML model of a data exchange may be specified in several ways. The best known are the remote procedure call (RPC) and the message-oriented styles.
When the RPC style of the data exchange model is used, the methods and the attributes (properties) of the communication interfaces must be defined as interfaces of the programming language. These methods and attributes may have additional marks (annotations) that specify an underlying message exchange pattern (MEP) such as request-reply, fire-and-forget, etc. In other words, the UML model specifies the application programming interface (API) of the RPC. It is the easy-to-read and compact notation that simplifies using other UML models, such as sequence diagrams and component diagrams. On the other hand, the API presentation can lead to misinterpretations because it hides the network nature of the RPC.
The message-oriented model contains the definition of the messages that are used to transfer the data between software components. This allows the creation of complex models of message processing flows, but the maintenance of such models may require additional effort.
There are several other decisions that must be made when designing a UML profile of the data exchange model. Data exchange in an infotainment network can be achieved using standard TCP/IP or proprietary protocols, such as the MOST application protocol. In case of the MOST protocol, it may not be necessary to create the UML profile of the PSM because the standard MOST XML format, which defines the MOST messages, already exists. So, the standard MOST XML format can be used instead of the PSM model to generate the MOST application code.
The discussion about all variations of the data exchange architecture exceeds the scope of this paper.
The UML PIM of the connection management is an extension of the deployment model. It specifies new UML constructions, representing allocations and defining the direction of the data transfer. The UML profile of the PIM contains four UML stereotypes: Synchronous Audio, Audio, Video and Data. The Synchronous Audio stereotype is used to identify an audio stream that includes several channels with identically sized patterns that are transferred synchronously. The Audio, Video and Data stereotypes are used to annotate the content of the stream with the specified bitrate. The Synchronous Audio, Audio and Video UML elements can be defined as protected. That means that the content of the corresponding streams will be protected using digital rights management (DRM) technologies, such as DTCP or HDCP.
The node, which sends the data, is a source UML element of the CommunicationPath connector, and the node, which receives the data, is the destination object of the same connector. For example, “Head Unit” is the source of the Main Stream, and “Amplifier” is its sink in the diagam below.
For larger image click here
The MOST-specific connection management model defines the stereotypes according to the types of the MOST streams: Synchronous, MDP, MEP, QoS IP, Audio/Video Packetized (A/V Packetized) and DFI. The block width in bytes for each of the MOST-specific streams must be specified.
The transformation from the PIM of an infotainment network to the PSM of the MOST network creates a new UML element for each stream of the PIM. That element represents the MOST-specific stream with the block width calculated from bitrate for Audio, Video and Data stereotypes or from the number of channels and the sample size for Synchronous Audio stereotype. The original streams’ connectors must be cloned for the MOST stream. Furthermore, the implementation connector may be used to depict the link between the MOST stream and the stream of the PIM, as shown on the Connection Management Diagram.
A MOST topology diagram may be used to specify the MOST network type and the topology of the MOST network. It depicts the physical topology of the MOST network and shows the nodes and the layout of the connections: ring, daisy chain, etc. This diagram can be very helpful by specifying the type of the port (USB, MLB etc.) chosen to connect the microcontroller (EHC) and INIC. This information may affect the generation of the configuration file if MLB is used.
The specification of the connection management in the form of the UML model can be used to generate source code or the configuration file. The source code is a part of the code used to realize the MOST application, but, in this case, the configuration cannot be modified without recompilation. Using the configuration file is more flexible. However, additional effort is needed to implement the parsing engine of the configuration file.
To simplify the implementation of the development tools, such as code generator, network monitors and testing scripts, an XML exchange format is necessary. This format has been proposed as a MOST Cooperation standard. Its XML schema includes the types representing the abstract platform-independent objects and optional XML elements called annotations refining the MOST-specific aspects of the platform-independent XML elements. The standard XML ID/IDREF types are used to link such elements as nodes, streams and software components.
This new XML format provides all information needed for the development tools and allows the designers, developers and testers to configure, monitor and analyze not only the data exchange in the infotainment network, but also the connections.
The platform-independent model of the infotainment network may be used to specify the system upon any dedicated technology for infotainment networking. However, MOST provides a solid methodology and powerful set of standards to cover all of the most important aspects of efficiently simplifying the design of the infotainment network.
References:
[1] 3.0E2 MOST Specification, MOST Cooperation
[2] Morgan & Claypool, 2012, Model-Driven Software Engineering in Practice, Marco Brambilla, Jordi Canot, Manuel Wimmer
[3] Addison-Wesley Professional, 2013, Software Architecture in Practice, Len Bass, Paul Clements, Rick Kazman
[4] IEEE, 2014, Obtaining Behavioral Model of PIM from the CIM, Abdelouahed Kriouile, Ahmed El Khadimi
[5] Development and Testing of Automotive, Ethernet-Networks together in one Tool – OMNeT++, Patrick Wunner, Stefan May, Kristian Trenkel, Sebastian Dengler
[6] Model-Driven Design of Network Aspects of Distributed Embedded Systems (IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 34, no. 4, April 2015), Emad Ebeid, Franco Fummi, Davide Quaglia
[7] Rev. 2.0, ormsc/2014-06-01, Model Driven Architecture (MDA), MDA Guide, Object Management Group
About the author:
Yury Asheshov has served as Principal Engineer for K2L GmbH & Co. KG since December 2015. Mr. Asheshov holds a Master of Science and a Bachelor of Science degree in Information Systems and Technologies from Saint Petersburg Electro-Technical University “LETI”, Russia.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
