Image Processing Reference
In-Depth Information
13.2.4 Multimedia Networks
Many protocols have been adapted or specifically conceived for transmitting the large amount of
data needed by emerging multimedia applications in automotive systems. Two prominent protocols
in this category are MOST and IDB-.
13.2.4.1 MOST Network
MOST (see Ref. []) is a multimedia network development, which was initiated in  by the MOST
Cooperation (a consortium of carmakers and component suppliers). MOST provides point-to-point
audio and video data transfer with different possible data rates. his supports end-user applications
like radios, global positioning system (GPS) navigation, video displays, and entertainment systems.
MOST's physical layer is a plastic optical fiber (POF) transmission support, which provides a much
better resilience to EMI and higher transmission rates than classical copper wires. Current produc-
tion cars, around  model series according to Ref. [], for instance from BMW and Daimler, employ
a MOST network, which is now becoming the de-facto standard for transporting audio and video
within vehicles (see Refs. [,]). At the time of writing, the third revision of MOST has been
announced with, as a new feature, the support of a channel that can transport standard Ethernet
frames.
13.2.4.2 IDB-1394 Network
IDB- is an automotive version of IEEE- for in-vehicle multimedia and telematic applications
jointlydevelopedbytheIDBForum(seehttp://www.idbforum.org)andtheTradeAssocia-
tion (see http://www.ta.org). The system architecture of IDB- permits existing IEEE-
consumer electronics devices to interoperate with embedded automotive grade devices. IDB-
supportsadatarateofMbpsovertwistedpairorPOF,withamaximumnumberofembedded
devices which are limited to  nodes. From the point of view of transmission rate and interoper-
ability with existing IEEE- consumer electronic devices, IDB- was at some time considered
a serious competitor for MOST technology but, despite a few early implementations at Renault and
Nissan, as far as we know the protocol did not reach wide acceptance on the market.
13.3 Middleware Layer
The design of automotive electronic systems has to take into account several constraints. First,
nowadays, the performance, quality, and safety of a vehicle depend on functions that are mainly
implemented in software (e.g., the ignition control, ABS, wipper control, etc.) and moreover depend
on a tight cooperation between these functions; e.g., the control of the engine is done according to
requests from the driver (speeding up, slowing down as transmitted by the throttle position sensor
or the brake pedal) and requirements from other embedded functions such as climate control or
ESP. Second, in-vehicle embedded systems are produced through a complex cooperative multipart-
ner development process shared between OEMs and suppliers. herefore, to increase the efficiency of
the production of components and their integration, two important problems have to be solved: ()
the portability of components from one ECU to another one enabling some flexibility in the archi-
tecture design, and () the reuse of components between platforms which is a keypoint especially
for ECU suppliers. So, the cooperative development process raises the problem of interoperability of
components. A classic approach for easing the integration of software components is to implement
a “MW layer” that provides application programs with common services and a common interface.
In particular, the common interface allows the design of an application disregarding the hardware
platform and the distribution, and therefore enables the designer focusing on the development and
the validation of the software components and the software architecture that realize a function.
 
Search WWH ::




Custom Search