Image Processing Reference
In-Depth Information
Among the set of common services usually provided by an MW, those that related to the
communication between several application components are crucial. They have to meet several
objectives:
•
Hide the distribution
through the availability of services and interfaces that are the
same for intra-ECU, inter-ECU, inter-domain communications whatever the underlying
protocols.
•
Hide the heterogeneity
of the platform by providing an interface independent of the under-
lying protocols, of the CPU architecture (e.g., // bits, Endianness), of the operating
systems (OS), etc.
•
Provide high-level services
to shorten the development time and increase quality
through the reuse of validated services (e.g., working mode management, redundancy
management, membership service, etc.). A good example of such a function is the
“frame-packing” (sometimes also called “signal multiplexing”) that enables application
components to exchange “signals” (e.g., the number of revolutions per minute, the speed
of the vehicle, the state of a light, etc.) while, at run-time, “frames” are transmitted over
the network; so, the frame-packing service of an MW consists in packing the signals
into frames and sending the frames at the right points in time for ensuring the deadline
constraint on each signal it contains.
•
Ensure QoS properties required by the application
,inparticular,itcanbenecessaryto
improvetheQoSprovidedbythelower-levelprotocolsas,e.g.,byfurnishinganadditional
CRC, transparent to the application, if the Hamming distance of the CRC specified by the
network protocol is not sufficient in regard to the dependability objectives. Other exam-
ples are the correction of “bugs” in lower level protocols such as the “inconsistent message
duplicate” of CAN (see Ref. []), the provision of a reliable acknowledgment service on
CAN, the status information on the data consumed by the application components (e.g.,
data were refreshed since last reading, its freshness constraint was not respected, etc.) or
filtering mechanisms (e.g., notify the application for each
k
reception or when the data
valuehaschangedinasigniicantway).
Note that a more advanced features would be to come up with adaptive communication services,
thanks to algorithms that would modify at run-time the parameters of the communication protocols
(e.g., priorities, transmission frequencies, etc.) according to the current requirements of the applica-
tion (e.g., inner-city driving or highway driving) or changing environmental conditions (e.g., EMI
level). For the time being, to the best of our knowledge, not such feature exists in automotive embed-
ded systems. In fact, this point requires a coordinated approach for the design of function (as the
definition of control law parameters, the identification of the parameters acting on the robustness
of the function, etc.) and the deployment of the software architecture that implements the function
(specifically the communication parameters). By increasing the efficiency and the robustness of the
application, such an adaptive strategy would certainly ease the reusability.
Some proprietary MW were developed by several carmakers to support the integration of ECUs
and software modules provided by their third-party suppliers. For instance, the TITUS/DBKOM
communication stack is a proprietary MW of Daimler that standardizes the cooperation between
components according to a client-server model. “Volcano” [,,] is a commercial product of Men-
tor Graphics, initially developed in partnership with Volvo. he Volcano Target Package consists of
a communication layer and a set of off-line configuration tools for application distributed on CAN
and/or LIN. It is aimed to provide the mapping of signals into frames under network bandwidth
optimization and ensure a predictable and deterministic real-time communication system thanks
to schedulability analysis techniques (see Refs. [,]). To the best of our knowledge, no publicly
available technically precise description of TITUS and Volcano exists.
