Conference Proceedings

Transcription

Conference Proceedings
International MOST Conference & Exhibition
30TH SEPTEMBER 2008
STUTTGART - GERMANY
Top Professionals from Automotive Electronics
Highlights and Future Technologies
MOST – The Multimedia Network
10 Years MOST Cooperation
30TH SEPTEMBER 2008
STUTTGART - GERMANY
MOST Connecting
Anzeige
The Automotive Infotainment Backbone
in over 60 vehicle models worldwide
Successful automotive standardization
Integrated Audio, Video and Ethernet data transmission
High data rates @ low latency
High quality of service
Automotive grade robustness
Cost optimized
16 Carmakers // 78 Suppliers
www.mostcooperation.com
2
MOST FORUM 2008 | CONFERENCE PROCEEDINGS
FORUM
MOST Is Ready
for the Future
The year of the MOST® Cooperation's 10th Anniversary is We are proud to celebrate our tenth anniversary that marks
highlighted with 94 member companies presenting an au- an outstanding automotive success story. Within only 10
tomotive success story: The third generation of the infotain- years MOST has been accepted as the de-facto standard for
ment backbone with faster data rates of 150 Mbps is being multimedia and infotainment networking in the automotive
standardized and robustness, quality and efficiency have industry. Already – only one decade after the first sketch of
been optimized. Today MOST is integrated in over 60 car the MOST ring structure – the third generation of the infotainment backbone with faster data rates of 150 Mbps even
models including the first Asian models.
offers an automotive-ready physical layer for Ethernet in the car.
Over 10 years ago BMW and Daimler together with Becker
(today Harman/Becker Automotive Systems) and OASIS The MOST Cooperation embraces the objective of the MOST
SiliconSystems (today SMSC) started cooperating on defining Forum to bring together top professionals from the autoand designing the Media Oriented Systems Transport Techno- motive electronics industry and academia to exchange inforlogy. With their clear vision the companies saw the need for mation and results of recent work on systems, circuits, techa common infotainment network standard instead of propri- nologies, processes and applications on MOST Technology.
etary solutions. The activities around MOST aim at concrete We support the conference to provide a forum for a broad
and measurable results for volume production rather than audience reaching from researchers, designers, engineers,
only defining a theoretical standard. In 1998 the companies system developers, to purchasers and journalists, and to the
founded the MOST Cooperation with Audi joining shortly managers of the industries involved. The MOST Cooperathereafter. They quickly developed the first specification since tion is participating to help our member companies further
they had to meet deadlines for mass production. Within only disseminate the knowledge learned in over a decade of
3 years BMW introduced the 7 series as the first MOST car intensive work. Our target is to provide a very high quality
in 2001. The following year 13 more models implemented conference to the attendees by encouraging our members
the MOST infotainment backbone. Now, 10 years later, 16 to share their experiences with this infotainment technology.
carmakers and their 78 premier suppliers contribute to the In addition we will be exhibiting a demonstration of the
latest developments of the MOST Cooperation.
success of the MOST Technology.
The MOST Cooperation
3
30TH SEPTEMBER 2008
STUTTGART - GERMANY
Welcome to
the MOST Forum
The 10th Anniversary of the MOST Cooperation is the motivation
behind launching the MOST Forum: The MOST Forum provides
an ideal venue to share ideas and experiences and to discuss the
latest news on this de-facto automotive infotainment standard.
Automotive electronics industry and academia meet on September 30, 2008, for this International MOST Conference and Exhibition in Stuttgart. The conference program covers a broad field
of topics with a wide range information on MOST infotainment
technology. During their presentations the speakers will discuss
MOST applications, experiences and technologies concerning
networking and system architecture, physical layer, compliance
and quality aspects, series projects experience, MOST and other
standards, as well as MOST in research and development.
On the evening of September 29, 2008, attendees can join for
the MOST networking event in Stuttgart. At 19.00 Harald Schöpp,
Member of the MOST Cooperation Steering Committee, will
inaugurate the MOST Forum. During the dinner attendees will
have the chance to meet influential people from the automotive
electronics industry. The media partners Electronic Design Group,
Elektronik automotive and ElektronikPraxis, as well as industry
partner ZVEI (Electrical and Electronic Manufacturers' Association),
are contributing their expertise and technology know-how.
In the exhibition area various companies present their MOST
solutions and applications. Amongst the exhibitors will be the
MOST Cooperation (presenting the MOST150 multimedia
demo), Avago Technologies, BMW Group, Comlet, Daimler AG,
Dension Audio Systems, GADV, K2L, LeCroy, MBtech, Ruetz
System Solutions, SMSC, and STEG.
Mandy Ahlendorf
MOST Forum
Imprint
Organizer of conference and exhibition
qaqadu event gmbh
Maximilianstrasse 8
82319 Starnberg / Germany
We are looking forward to a great MOST Forum with presentations of innovative solutions and highlights on MOST and its
applications.
t +49 8151 555009 11
F +49 8151 555009 10
e contact@mostforum.com
W www.mostforum.com
© 2008 by qaqadu event gmbh
All rights reserved, including reprint, copying (photocopy, microscopy) and the translation, partially or completely. The MOST Forum Conference Proceedings, the lectures of the
conference, are published as unrevised manuscripts. The individual contributions are subject to the evidence-based personal views and experiences of their respective speakers
and authors.
The qaqadu event gmbh is not responsible for the contributions to the MOST Forum and distances itself expressly from the contents of all third parties’ website. The qaqadu
event gmbh does not assume and hereby disclaims any liability to any person for any loss or damage caused by statements, errors or omissions in the material contained herein,
regardless of whether such errors result form negligence, accident or any other cause whatsoever.
4
FORUM
Thank you to all Partners and Exhibitors!
Program Committee
Stephan Esch, AUDI AG
Prof. Dr. Andreas Grzemba,
University of Applied Sciences Deggendorf
Stephan Janouch, Elektronik automotive
Jochen Klaus-Wagenbrenner, Harman/Becker
Knowledge Partner
Robert Reiter, BMW Group
Harald Schöpp, SMSC
Dieter Seidl, Daimler AG
Christoph Stoppok, ZVEI
Johann Wiesböck, ElektronikPraxis
Industry Partner
Media Partners
Exhibitors
5
30TH SEPTEMBER 2008
STUTTGART - GERMANY
Content
Networking Evening / Conference and Exhibition
Authors
Conference Program
Partner Profiles
Exhibitor Profiles
8
10
11
12
14
Technical Papers
Keynote
Networking Vehicle Infotainment Systems with MOST
Dr. Alexander Leonhardi, Daimler
19
MOST Networking and System Architecture
MOST150 – The New Generation of the Infotainment Backbone
23
MOST Simulation Framework
M. Eng. Andreas Schramm, BMW Group
Dr. Donal Heffernan, University of Limerick
Richard Wurm, University of Applied Sciences Deggendorf
29
Proposal for a MOST150/Ethernet Gateway
33
H.264 Low-latency Video Compression in Automotive Applications
Dipl.-Ing. Ralf M. Schreier, On Demand Microelectronics
37
Software Implementation of MLB on the MPC5517
Jürgen Frank, Freescale
41
MOST and Other Standards
Usage of AUTOSAR Diagnostic Modules in a MOST Electronic Control Unit
Paul Hoser, BMW Car IT GmbH
6
45
FORUM
MOST Physical Layer
Plastic Optical Fiber Coupling Systems: A Novel Opto-mechanical Modeling Approach
Els Moens, Vrije Universiteit Brussel
Michael Vervaeke, Vrije Universiteit Brussel
Youri Meuret, Vrije Universiteit Brussel
Heidi Ottevaere, Vrije Universiteit Brussel
Carl Van Buggenhout, Melexis Ieper NV
Piet De Pauw, Melexis Ieper NV
Hugo Thienpont, Vrije Universiteit Brussel
51
nanoStructures™ Technology and Possibilities for the Next Generation
of Optical Fibers for Vehicular Applications
Claudio Mazzali, Corning Incorporated
Paulo Dainese, Corning Incorporated
Mike Pambianchi, Corning Incorporated
Manish Sharma, Corning Incorporated
Guenther Uhlenhuth, Corning Incorporated
57
MOST Compliance and Quality
Automotive Application Recommendation for MOST150 Physical Layer Components
Joerg Angstenberger, RELNETyX AG
Dr. Viktor Tiederle, RELNETyX AG
61
High Quality System Integration
Wolfgang Malek, RUETZ SYSTEM SOUTIONS
Georg Janker, RUETZ SYSTEM SOLUTIONS
65
MOST Series Projects Experience
Error Handling Strategies for a MOST Application Framework
Dr. Alexander Leonhardi, Daimler AG
Torsten Pech, Daimler AG
Andreas Vallentin, Daimler AG
69
MOST Networking and System Architecture
AUDI Q5: Evolution of a MOST System Architecture
Uwe Hackl, AUDI AG
75
CD ROM: Conference Proceedings
CD ROM: MOST Electric Brochure and MOST Book
79
7
30TH SEPTEMBER 2008
STUTTGART - GERMANY
Networking Event
September 29, 2008
19.00 open end
Location: mash restaurant
On the evening of September 29th, 2008, all participants are
invited to join for the MOST infotainment event in Stuttgart.
At 19.00 Harald Schöpp, Member of the MOST Cooperation Steering Committee, will inaugurate the MOST Forum.
During the dinner attendants have the chance to meet influential people from the automotive electronics industry. Participants are welcome to discuss latest MOST Technologies
and developments and learn about key changes coming up.
The networking event takes place at the mash restaurant in
Stuttgart which is located in the BOSCH Areal right next to
the Liederhalle:
mash
Forststrasse 7
70174 Stuttgart
Germany
T +49 711 1209330
W www.mash-stuttgart.de
8
FORUM
Conference & Exhibition
September 30, 2008
8.00 – 18.00
Location: Schiller conference
room and foyer at the Liederhalle
Cultural & Congress Center
On September 30, 2008, MOST Forum 2008, the international MOST Conference and Exhibition, invites its
attendees to the Liederhalle Cultural & Congress Center in
Stuttgart, Germany, to a one-day congress with numerous
specialists presenting the latest and future technologies
and applications on MOST based infotainment technology.
The conference will provide a forum for a broad audience
reaching from researchers, designers, engineers, system
developers, to purchasers and journalists, and to the managers of the industries involved. The Liederhalle Cultural and
Congress Center is located in Stuttgart right in the middle of
one of the strongest economic region in Germany.
Kultur- & Kongresszentrum Liederhalle (KKL)
Berliner Platz 1-3
70174 Stuttgart
Germany
T +49 711/20 27 710
W www.liederhalle-stuttgart.de
9
30TH SEPTEMBER 2008
STUTTGART - GERMANY
Authors
10
Joerg Angstenberger
RELNETyX AG
Carl Van Buggenhout
Melexis Ieper NV
Paulo Dainese
Corning Incorporated
Juergen Frank
Freescale
Uwe Hackl
AUDI AG
Dr. Donal Heffernan
University of Limerick
Paul Hoser
BMW Car IT GmbH
Georg Janker
RUETZ SYSTEM SOLUTIONS
Dr. Alexander Leonhardi
Daimler AG
Wolfgang Malek
RUETZ SYSTEM SOUTIONS
Claudio Mazzali
Youri Meuret
Vrije Universiteit Brussel
Els Moens
Heidi Ottevaere
Dr. Michael Pambianchi
Piet De Pauw
Melexis Ieper NV
Torsten Pech
Daimler AG
Harald Schöpp
SMSC
Andreas Schramm
BMW Group
Ralf M. Schreier
On Demand Microelectronics
Manish Sharma
Hugo Thienpont
Dr. Viktor Tiederle
RELNETyX AG
Guenther Uhlenhuth
Andreas Vallentin
Daimler AG
Michael Vervaeke
Richard Wurm
FORUM
Conference Program
8.00
9.00
9.15
9.45
10.15
10.45
11.15
11.45
12.15
12.45
Registration and Reception Coffee
Exhibition Opens
Opening and Welcoming Speech
Networking Vehicle Infotainment Systems with MOST
Keynote Speech
MOST150-the New Infotainment Backbone for Automotive Applications
MOST150 Simulation Framework / Proposal for MOST150/Ethernet Gateway Implementation
Andreas Schramm / Richard Wurm, BMW Group
MOST Networking
and System
Coffee Break / Networking / Exhibition
Architecture
H.264 Low-latency Video Compression in Automotive Applications
Ralf Schreier, On Demand Microelectronics
SoftMLB on the MPC5517
Juergen Frank, Freescale
Useage of AUTOSAR Diagnosis Modules in a MOST ECU
MOST
Paul Hoser, BMW Car IT
and Other Standards
Lunch / Networking / Exhibition
Plastic Optical Fiber Coupling Sytems: A Novel Opto-mechanical Modelling Approach
14.15
14.45
Dr. Youri Meuret / Els Moens / Dr. Heidi Ottevaere / Prof. Dr. Hugo Thienpont
Dr. Michael Vervaeke, Vrije Universiteit Brussel
MOST
Carl Van Buggenhout / Dr. Piet De Pauw, Melexis
Physical
nanoStructuresTM Technology and Possibilities for the Next Generation of Optical Fibers
Layer
for Vehicular Applications
Dr. Michael Pambianchi , Corning Inc.
Automotive Application Recommendation for MOST150 Physical Layer Components
15.15
Joerg Angstenberger / Dr. Viktor Tiederle, RELNETyX
MOST Compliance
and Quality
Georg Janker / Wolfgang Malek, Ruetz System Solutions
15.45
16.15
16.45
Coffee Break / Networking / Exhibition
Error Handling Strategies for a MOST Application Framework
MOST Series
Dr. Alexander Leonhardi / Torsten Pech / Andreas Vallentin, Daimler
Projects Experience
MOST Networking and
Uwe Hackl, AUDI AG
System Architecture
17.15
Conclusion and End of Conference
18.00
Exhibition Closes
11
30TH SEPTEMBER 2008
STUTTGART - GERMANY
K N O WL ED GE PA R TN E R
The MOST Cooperation is the organization through which
MOST Technology is standardized and refined so that it continues to stay abreast of the latest industry requirements. Today
it consists of 16 international carmakers and more than 75
CONTACT
key component suppliers. They have joined together to work
with the MOST Technology and to contribute to its innovation. The MOST Cooperation is prepared to embrace efforts
to further develop and standardize the technology for other
industries and to establish the corresponding work structures.
The MOST Cooperation was founded in 1998 to standardize
MOST (Media Oriented Systems Transport) is a multimedia MOST Technology as a global standard for multimedia netnetworking technology optimized for use in cars and other working. Audi, BMW, Daimler, Harman/Becker and SMSC are
applications. It enables the transport of high Quality of Ser- its core partners and constitute its Steering Committee.
vice audio and video together with packet data and real-time
control over a single transmission medium. MOST can use
plastic optical fiber or electrical unshielded or shielded twisted pair wire physical layers, that meet automotive environmental requirements. Today MOST is used in over 60 car models as the communication backbone for their information
MOST Cooperation
and entertainment equipment.
Bannwaldallee 48
76185 Karlsruhe
Germany
E contact@mostcooperation.com
W www.mostcooperation.com
I N D U STRY PA R TN ER
12
CONTACT
To safeguard common interests, to exchange experience, to
provide information: The 'ZVEI - Zentralverband Elektrotechnik- und Elektronikindustrie e.V.', the German Electrical and
Electronic Manufacturers' Association, represents the economic, technological and environmental policy interests of
the German electrical and electronics industry at the national, European and international levels. It provides specific
information about the economic, technical and regulatory
framework conditions of the electrical industry in Germany.
The ZVEI promotes the development and use of innovative
technologies by proposals concerning research, technological, environmental protection, educational and scientific policy. It supports market-orientated European and international
standards-making activities. ZVEI's close contacts with politi-
cal quarters and public administrations and the association's
internal exchange of experience and views provide extensive
information about market- and competition-related developments, which is tailored to the electrical and electronic
industry's specific needs. The member companies use this
lead in knowledge and experience to improve their international competitiveness.
ZVEI - Zentralverband Elektrotechnik- und
Elektronikindustrie e.V.
Lyoner Strasse 9
60528 Frankfurt am Main
Germany
T +49 69 6302 0
E info@zvei.org
W www.zvei.org
FORUM
ME D I A PA R TN ERS
CONTACT
from Germany, Under the Hood, Executive Viewpoints, and
New Products. Topics covered include Hybrid Electric Vehicles,
Powertrain, Data Buses/In-Vehicle Networking, Body Electronics, Human Machine Interface (HMI), Telematics/In-Vehicle
Navigation, Testing & Simulation, Multimedia, Embedded
Auto Electronics is the publication of Penton Media's Elect- Systems, Sensors & Security, On-Board Vehicle Diagnostics,
ronic Design Group focused exclusively on the automotive Active & Passive Safety Systems, and Solid-State Lighting.
segment of the electronics industry. Published six times a year
Electronic Design Group - Penton Media
Auto Electronics examines the electronics trends and design
45 Eisenhower Dr., Suite 550
issues in the automotive industry today. From powertrain to xParamus, NJ 07652-1452
by-wire, Auto Electronics delivers in-depth design informatiUnited States
on and how-to details to keep engineers up to date on all asT +1 201 845 2467
E mdavid@penton.com
pects of automotive electronics. Each issue features a Special
W www.electronicdesign.com
Report cover story, Technical Features, Technology Update
CONTACT
driver assistant systems and cross-linking. Another focus of
the editorial coverage is on cross section such as software
development, development and simulation tools as well as
Elektronik automotive, the technical magazine for automo- the various standardisation initiatives. Apart from in depth
tive electronics and telematics, is custom-made for design technical specialist articles, Elektronik automotive also covers
engineers and decision makers within research, development news, technical trends, market data and product news.
and technical management, in the construction of vehicles
Elektronik automotive
and the supporting industries. Elektronik automotive takes
Gruber
Strasse 46a
up detailed current and important automotive-electronics
85586 Poing
developments. The editorial coverage ranges from microeGermany
lectronics and mechatronics to measuring and inspection
T +49 8121 95 1369
E sjanouch@elektronik.de
techniques in the fields of comfort, safety electronics, powW www.elektroniknet.de
ertrain, electrical systems, chassis electronics, infotainment,
CONTACT
ELEKTRONIKPRAXIS is the professional electronics magazine
which in a bi-weekly interval, reports on what is going on
in the electronics industry as well as new products, technologies and development procedures. ELEKTRONIKPRAXIS
supplies information for hardware and software developers,
purchasers, specialists for assembly and packaging technology, component production as well as decision makers in
German-speaking countries. In addition to the contents of
the 24 main issues, the magazine summarizes key topics in
another 16 special feature issues. Furthermore 12 reports for
embedded software engineers and automotive electronics
engineers, each with six issues, are published. www.elektronikpraxis.de offers a broad spectrum of in-depth engineering
and product information along with the latest news from the
electronics industry on an interactive multi-media platform.
Vogel Industrie Medien GmbH & Co.KG
Redaktion ELEKTRONIKPRAXIS
Max-Planck-Strasse 7/9
97082 Würzburg
Germany
T +49 931 418 0
E redaktion@elektronikpraxis.de
W www.elelektronikpraxis.de
13
30TH SEPTEMBER 2008
STUTTGART - GERMANY
E X H I BI TORS
For 40 years, Avago Technologies has been providing innovative products which enable manufacturers to break new
ground, create new markets and lead existing ones. Backed
by strong customer service support, Avago's products serve
four diverse end markets: industrial and automotive, wired
infrastructure, wireless communications, and computer peripherals. We are a leading global supplier of industrial fiber
optic products, with manufacturing and testing procedures
that produce the industry’s most reliable devices for industrial,
automotive and power generation applications.
For the automotive market, Avago has R&D, manufacturing and sales offices located in Regensburg, Germany. As a
pioneer in the optics industry, Avago is boosting the performance of in-car infotainment systems with our MOST® optical components, which extend network signal quality and
CONTACT
operating temperatures range well beyond competitive products. Leveraging our extensive expertise and commitment
to high-quality products, Avago’s MOST-based plastic fiber
optic transceivers are used today by leading automotive manufacturers world-wide.
Avago Technologies
Bernd Luecke
Wernerwerkstrasse 2
93049 Regensburg
Germany
T +49 941 29784126
F +49 941 29784250
E bernd.luecke@avagotech.com
W www.avagotech.com
CONTACT
Our business activities include:
• Consulting: technological consulting, architecture design,
code optimisation
• Engineering: Networking (MOST, CAN, LIN), RS232/RS485,
Bluetooth, MMI-modelling, voice control, diagnosis, percomlet Verteilte Systeme GmbH develops customer-specific
formance optimization, circuit design, creation of protosoftware solutions for the control and networking of embedtypes
ded systems in automobiles. comlet’s headquarters is in Zwei- • Integration and test: integration planning, automated test
brücken with a branch office in Stuttgart. comlet can proudly
cases, PC simulations
look back on several years of project experience, especially • Maintenance: System maintenance, Bugtracking/Bugin the area of car infotainment. As well as embedding multifixing, Changemanagement
media devices and navigation systems into the MOST ring,
another of our tasks is the continual development of new
comlet Verteilte Systeme GmbH
Elena Gorodnikova
features.
Amerikastrasse
27
We support our customers during the conception phase with
66482 Zweibrücken
architecture design and evaluation and optimize the software
Germany
in regard to speed, stability or resources requirement. We
T +49 6332 811 130
F +49 6332 811 315
undertake complete development projects, individual work
E elena.gorodnikova@comlet.de
packages or support your engineering team on site.
14
W www.comlet.de
FORUM
E X H I B I TORS
CONTACT
Dension will be demonstrating the Network Attached Storage
& Data Gateway concept for MOST150 enabling shared data
storage and wireless data access for multiple MOST nodes.
This new concept brings the benefits of mass storage and acFounded in 2001, Dension initially provided mass storage-ba- cess to external bandwidth to all applications within a MOST
sed media players for in-vehicle applications. We pioneered network. We welcome discussions with Forum participants
the integration of the Apple iPod and other consumer elec- on applications of this new and exciting concept.
tronics and IT devices with legacy vehicle infotainment systems and have a history of industry firsts including the world’s
first MOST-based iPod interface. With a focused development
Dension Audio Systems KFT
and supply program to vehicle manufacturers, we operate
Jozsef Lukacs
Sztregova u. 1.
TS16949-approved development and production facilities. Our
Budapest 1116
Budapest-based R&D Centre is today involved in the developHungary
ment of advanced in-vehicle applications and the associated
T +36 1 4630470
F +36 1 4630479
infrastructure to support connected multimedia applications
E jlukacs@dension.com
enabling us to serve vehicle makers at all levels from system
W www.dension.com
design to contract manufacturing. At MOST Forum 2008
K2L is an independent German software development company with an international team. The area of work covers all
phases of software development for embedded as well as PC
based mass- production products and tooling. The most important firmware products are application frameworks and
gateways between all leading edge automotive networks like
CAN, MOST, FlexRay, LIN and Ethernet.
CONTACT
CONTACT
production. GADV is member of the MOST Cooperation. Because
of the outstanding expertise in MOST technology and test knowhow GADV was selected as first MOST Compliance Test House
GADV is an independent software vendor. For 3 decades GADV (MCTH). GADV is an accredited test laboratory according to ISO
cooperates with midrange and large industrial companies in auto- 17025 for MOST Core and Profile Compliance.
mation and rationalization projects. Our versatile automation and
data processing solutions are focused on technical-administrative
GADVmbH
Thomas Gelsdorf
systems as well as on automation of technical processes. Since
Schafgasse 3
establishment in 1977 GADV is specialized in reliable software and
71032 Böblingen
system development. Many software systems are installed at car
Germany
manufacturers and their suppliers world wide. Many partners in
T +49 7031 7196 21
F +49 7031 7196 49
the engine building industry and manufacturers of medical equipE
thomas.gelsdorf@gadv.de
ment rely on our software. Our solutions accompany our customers
W www.gadv.de
products live cycle from pre-development up to round the clock
K2L GmbH
Thomas Keicher
Mannheimer Strasse 17
75179 Pforzheim
Germany
T +49 7231 95688 60
F +49 7231 95688 65
E bestellungen@k2l.de
W www.k2l.de
15
30TH SEPTEMBER 2008
STUTTGART - GERMANY
E X H I BI TORS
LeCroy Corporation is a worldwide leader in serial data test
solutions, creating advanced instruments that drive product
innovation by quickly measuring, analyzing, and verifying
complex electronic signals. The Company offers a wide range of high-performance digital oscilloscopes from 60 MHz
to 100 GHz bandwidth, serial data analyzers, serial bus test
solutions (MOST, CAN, FlexRay, I2C, SPI, UART etc.), mixed
signal text solutions, and global communications protocol
test solutions used by design engineers in the computer, embedded and semiconductor, data storage device, automotive
and industrial, and military and aerospace markets. LeCroy’s
40-year heritage of technical innovation is the foundation for
its recognized leadership in “WaveShape Analysis”— capturing, viewing, and measuring the high-speed signals that
drive today's information and communications technologies.
CONTACT
LeCroy is headquartered in New York. The European headquarters are located in Geneva. More information about
LeCroy, its products and solutions is available at http://www.
lecroy.com.
LeCroy Europe
Uwe Karstens
Waldhofer Strasse 104
69123 Heidelberg
Germany
T +49 6221 82700
F +49 6221 834655
E contact.gmbh@lecroy.com
W www.lecroy.de
Highly experienced in all phases of the product development
lifecycle with extensive knowledge of functional integration,
software and microcontrollers for networked vehicle systems,
MBtech is capable of taking over the entire electrical/elec-
16
CONTACT
tronics development of vehicle variants. Its methods, tools
and reference process set high benchmarks in the industry
and it actively participates in the design and development of
industry- and customer-specific standards. MBtech takes care
of quality, reliability and functional safety through the consequent testing and validation of ECUs, networked systems,
The MBtech Group is a globally active and internationally lea- components and processes.
ding automotive engineering and consulting company with
approximately 2,500 employees located throughout Europe, North America and Asia. MBtech’s competence extends
throughout the product development process and over the
entire product lifecycle. MBtech’s products and services focus
on four areas: MBtech vehicle engineering, MBtech powMB-technology GmbH
ertrain solutions, MBtech electronics solutions and MBtech
Frank Cau
consulting.
Kolumbustrasse 2
71063 Sindelfingen
Germany
T +49 7031 686 3100
E info@MBtech-group.com
W www.mbtech-group.com
FORUM
E X H I B I TORS
CONTACT
Ethernet packet transport, multi-channel video streaming
from HDD as well as isochronous streaming of HDTV and
SDTV. In addition to higher bandwidth, MOST150 features
an isochronous transport mechanism to support extensive
video applications, as well as an Ethernet channel for efficient seamless transport of IP-based packet data. The Ethernet
MOST (Media Oriented Systems Transport) is the multimedia channel can transport unmodified Ethernet frames as specinetworking technology optimized for use in cars and other fied by IEEE 802.3. This enables software stacks and applicaapplications. Today MOST is used in over 60 car models as tions from the consumer and IT domain, where the speed of
the communication backbone for their information and en- innovation is much faster, to be seamlessly migrated into the
tertainment equipment. The MOST Cooperation is the orga- car. TCP/IP stacks or protocols that use TCP/IP can communinization through which MOST Technology is standardized cate via MOST without modification.
and refined so that it continues to stay abreast of the latest
industry requirements. Today it consists of 16 international
carmakers and more than 75 key component suppliers. Audi,
BMW, Daimler, Harman/Becker and SMSC are its core partMOST Cooperation
ners and constitute its Steering Committee.
Bannwaldallee 48
76185 Karlsruhe
At the MOST Forum the MOST Cooperation Presents the AuGermany
tomotive-ready Physical Layer for Ethernet in the Car: The
E contact@mostcooperation.com
Cooperation will display how MOST can be used as an auW www.mostcooperation.com
tomotive Ethernet physical layer. The multimedia demonstration shows MOST at 150 Mbps bandwidth with high-speed
The company RUETZ SYSTEM SOLUTIONS is specialized in car
infotainment based on MOST technology: We offer consulting services tailored to the needs of our customers in the
car industry, advising you on specification and development
of MOST compatible components and devices and on the
design of appropriate test series. As a test house accredited
by the MOST Cooperation, we support engineers working
in systems integration and testing through all steps of the
process required for newly developed devices and components to comply with MOST Compliance, up to certification
of control units according to the binding standards set by the
MOST Cooperation.
Our consulting and training services are further enhanced
by a full product portfolio, which companies can use to car-
CONTACT
ry out network, component and application testing. RUETZ
SYSTEME SOLUTIONS supports not only MOST25 oPhy,
MOST50 ePhy but also MOST150 oPhy.
Ruetz System Solutions GmbH
Wolfgang Malek
Ingolstädterstrasse 18
80807 München
Germany
T +49 89 35610 190
F +49 89 35610 111
E wolfgang.malek@ruetz.de
W www.ruetz-system-solutions.com
17
30TH SEPTEMBER 2008
STUTTGART - GERMANY
E X H I BI TORS
Many of the world's most successful global technology companies rely upon SMSC as a go-to resource for semiconductor
system solutions that span analog, digital and mixed-signal
technologies. Leveraging substantial intellectual property, integration expertise and a comprehensive global infrastructure,
SMSC solves design challenges and delivers performance,
space, cost and time-to-market advantages to its customers.
SMSC's application focus targets key vertical markets including consumer electronics, automotive infotainment, PC and
industrial applications. The Company has developed leadership positions in its select markets by providing application
specific solutions such as mixed-signal embedded controllers, non-PCI Ethernet, ARCNET, MOST and Hi-Speed USB.
SMSC is a supplier to many automakers for MOST-based infotainment semiconductor solutions, including Audi, BMW,
CONTACT
Daimler, Hyundai, Kia, Land Rover, Porsche, Saab, Toyota and
Volvo. SMSC is headquartered in Hauppauge, New York with
operations in North America, Asia and Europe. Engineering
design centers are located in Arizona, New York, Texas and
Karlsruhe, Germany.
SMSC Europe GmbH
Bannwaldallee 48
76185 Karlsruhe
Germany
T +49 721 625 37 0
F +49 721 625 37 119
E ais@SMSC.com
W www.smsc-ais.com
CONTACT
the others side (e.g. Aftermarket system). Kamaleon is a
modular embedded system based on Blackfin processor. It’s
able to play AuxIN, AudioAmplifier (included DSP functionalities), Telephone, PhoneBook and even more Fblock on a
STEG is a GT Trading s.r.l. brand. GT Trading is an Italian com- MOST network. Its modularity is due to slots (like those on a
pany leader on develop and produce Hi-END Audio Amplifiers PC) where is possible to insert specific boards each one defor automotive aftermarket since 1986 under its brands dicated to some kind of consumer electronic interfaces (e.g.
STEG, AUDIO SYSTEM, and also for some OEM aftermar- Hi-end Digital to Analog Audio conversion Board up to 8
ket customers like ETON, BOSTON ACOUSTICS and CIARE. channel starting from 115dB SNR, Digital Audio interface
GT Trading products are famous for their very Hi-End audio Board, Bluetooth+USB and IPOD interface Board, WI-FI).
quality, certified even by several EISA awards. GT Trading
sell its products worldwide in more than 40 countries. Now
GT Trading is focusing its efforts on MOST bus realizing that
GT Trading SRL
Claudio Casagrande
it has became a de-facto standard for automotive infotainVia
ca Balzano
ment systems. From that born STEG Kamaleon the first after61034 Fossombrone
market MOST audio gateway. It allows end users to improve
Italy
audio quality and integrate consumer electronic devices into
T +39 0721723727
F +39 0721749175
the OEM MOST system. The Kamaleon purposes is to ensuE claudio.casagrande@gttrading.it
re the integrity of each system while making the resources
W www.gttrading.it
available on one side (e.g. OEM system) to the devices on
18
FORUM
K E Y N OTE
Networking Vehicle Infotainment Systems
with MOST
Dr. Alexander Leonhardi, Daimler
1. Introduction
Vehicle infotainment systems providing entertainment, navigation and communication functions have become standard
features of high-end vehicles. In spite of the current trend to integrate more of their functionality into a single device, the
head-unit, advanced vehicle infotainment systems are still distributed systems. Besides other reasons against such a high integration, some functions will not be integrated into the head-unit a) because they are optional or specific to a certain market,
like current satellite radio or TV tuners, b) because of packaging restraints, for example in case of a high-end amplifier, or c)
because they provide a user interface for rear-seat passengers. Therefore, there will always be the requirement to connect
such devices via a suitable communication network.
Since the founding of the MOST cooperation in 1998, the MOST bus has become the de-facto standard in high-end vehicles.
It provides the means to transmit multimedia data, control commands and mass data over a single bus system. Most important, as the MOST bus has been developed specifically for the automotive domain, it satisfies all of its specific requirements.
However, in the fast moving infotainment and navigation world, the MOST bus has to support new upcoming features and
to compete with other bus systems continually.
In the next section of this paper we will discuss the different aspects that are important for a system integrator (i.e., a car
manufacturer) when selecting a communication network for its infotainment system. In Section 3, we will use these aspects
to consider the current status of the MOST standard and its ecosystem, that is the primary and supporting technologies and
the companies that are able to provide them. Finally, we will conclude the paper with a summary of the status and point out
future directions for the development of the MOST standard.
2. Criteria for Selecting an Infotainment Network
From a system integrator’s point of view technological aspects are
only one important factor when selecting a bus system for a vehicle
infotainment system. Instead, a combination of the following aspects has to be considered (see Figure 1):
• the primary technology and its HW and SW components
• the availability of supporting technologies and interfaces
• the access to know-how regarding development
• the availability of tools for development and testing
Theoretically, it is possible to influence the latter three aspects prior
Figure 1: Different important aspects for selecting a communicaand during development of the system by contributing to standardition system with examples from the MOST standard.
zation efforts and by triggering respective developments. However,
experience has shown that for such a complex technology as a bus
system this requires a great effort and the results are limited. Therefore, a system integrator should follow a long term strategy when selecting a communication networks.
19
30TH SEPTEMBER 2008
STUTTGART - GERMANY
In the fast moving environment of the entertainment, navigation and communication sector, it is also important for a long
term strategy to consider the future perspective of a technology. Even if the technology is suitable for a current system, it also
has to have potential and a roadmap for the next anticipated generation.
3. Reflections on the Status of the MOST Standard
In the following sub sections we outline the current status of the MOST standard regarding the aspects discussed in the
previous section.
3.1. MOST Technology
The optical physical layer of the MOST bus based on plastic optical fibre (POF) greatly reduces the problems caused by electromagnetic interference, while permitting a high bandwidth. In has now been used successfully in vehicles on the road for
seven years. With the electrical and the glass fibre physical layer alternatives for usage areas with other requirements are
available.
Furthermore, the synchronous nature of the data transmission – with a frame rate that can be adjusted to the available
audio sources (usually 44.1 kHz or 48 kHz) – provides for the uncomplicated transmission of audio data. This makes it easy
for simple devices, like an external CD-changer or an audio amplifier, to transmit or to receive audio streams. In comparison,
non-synchronous bus systems like Ethernet, which are usually optimized for the transmission of data packets, have to provide
concepts for synchronization and buffering to transmit multimedia data.
With a bandwidth of up to 25 MBit/s, the current MOST bus (MOST25) has enough bandwidth for today’s infotainment
systems, which use the MOST bus for the transmission of control information, for the transmission of limited amounts of
data, but mainly for audio transmission. The next version of the MOST bus with a bandwidth of 150 MBit/s (MOST150) will
be ready for the next generation of infotainment systems and the transmission of video data [5].
The first generation of Network Interface Controllers (NICs) of the OS8104 family [8] is currently being replaced by the INIC
(Intelligent NIC, OS81050 [9]). The INIC incorporates functions formerly performed by the host controller thus allowing
for a simpler and more robust system design. The NetServices [7] are a standard, largely hardware independent driver for
accessing the NICs and INICs and are available in the versions 1.x and 2.x respectively. INIC and NetServices for the MOST150
are available as first engineering samples.
3.2. Supporting Technologies and Interfaces
While the MOST standard defines the communication between separate MOST devices [4], for the design of a device itself an
easy (i.e., via standard interfaces) and high-performance access to the transmitted data via the Network Interface Controller
is required. With the increased need for higher volume data transmission, for example for the data services of digital radio or
for the meta data of a music player, an efficient access to the packet data channel is important.
Implementing faster data transmission via the packet data channel was difficult and expensive using the OS8104 because it
required the use of a proprietary interface, the Parallel Combined Mode. Beginning with the INIC, the Media Local Bus (MLB)
interface has been introduced. Currently, several processors from the automotive domain support the MLB (see, for example,
[2]), thus making it much easier to realize devices that have a good performance for packet data.
Further support is required for implementing content protection for transmission of audio (and video). Here the MOST bus
makes use of the DTCP standard. Respective implementations for audio streams have already been available for some time.
SMSC also has announced a companion chip that translates MLB to various standard interfaces, including the Host Bus Interface for fast access to packet data, and supports en- and decryption for streaming data according to DTCP (see [10]).
To enable the transmission of video on MOST, solutions for the encoding and decoding of video streams with direct interfaces
for the MOST bus are required. However, while such solutions are under development, no solution is available yet.
20
FORUM
3.3. Know-how Regarding System Development
Equally important as an automotive technology itself is the know-how and experiences regarding its use in real vehicle
projects. The MOST Cooperation supports the implementation of MOST systems with different application recommendations for the physical layer, e.g. describing the implementation and qualification of its optical components [3]. Additionally,
a standardized set of tests on the physical and core network level has been defined for the compliance process.
On the application level, the MOST standard also defines an application framework including proven interfaces for common functions of a vehicle infotainment system, such as an audio amplifier, a radio tuner or a gateway for a mobile media
player. Car manufacturers and suppliers have extended these interfaces for their specific systems and defined further mechanisms and guidelines for application communication and error handling. In addition to the application interfaces the MOST
standard also defines guidelines for the description of the static and dynamic behaviour (see, for example, [6]) and an XMLbased format, which is supported by almost all available tools, for the exchange of interface definitions.
While at the beginning all software components besides the NetServices had to be developed by the supplier of a MOST
device, currently software platforms and components are beginning to emerge that provide different aspects of a MOST
application framework.
3.4. Tools for Development and Testing
To support the development process of an infotainment system as well as its extensive testing, which is necessary to achieve
the quality expected in high-end vehicles, an appropriate set of tools has to be available. In our case it is important that these
tools support the specific properties of the MOST bus, for example the special notations and formats used for the definition
and exchange of MOST communication interfaces. The tools must also be suitable for the use in an automotive environment.
For the testing of a MOST system in an automotive environment, appropriate hardware and software tools are now available from different suppliers. This includes rapid prototyping tools, network analysis tools that are used on test benches and
autonomous data loggers that can be used in a test car. Ideally, at least the data loggers should support other vehicle networks such as CAN to allow for the analysis of cross-domain problems. Most of these tools have already been used successfully in different system integration projects. While support for the packet data channels has been missing in the first tools,
it is now supported by virtually all of them.
Common development tools for a MOST system, such as an editor for a function catalogue or for Message Sequence Charts
(MSCs) [1], are also available. However, system integrators are still mainly using a proprietary tool chain, which is difficult to
maintain and to extend.
4. Conclusion
From its beginnings in 1998 the MOST bus has become the de-facto standard for networking high-end automotive infotainment systems and is today used in over 55 car models. Its technological aspects make the MOST bus a good choice for
networking the devices of a distributed infotainment system and the current components and mechanisms have now proven
successful in seven years of use in vehicles on the road. Additionally, more and more companies are adding know-how to the
MOST ecosystem, thus increasing the pool of components, tools and technologies a system integrator can rely on to design
and test its infotainment systems.
However, the MOST community – because of its limited application area – has difficulties in keeping up with the speed of
the entertainment and Internet world. While at the beginning the MOST bus had to develop all the special mechanisms and
interfaces to be ready for use in the automotive environment, the next challenge is to adopt mechanisms of and to provide
interfaces to the IT, Internet and entertainment world in order to be able to participate in the fast development of this sector
without losing the suitability for the automotive environment. A first steps in this direction is the development of the Ethernet
channel for the MOST150. However, further steps are needed to be able to employ software application from higher layers
and tools from the IT world.
21
30TH SEPTEMBER 2008
STUTTGART - GERMANY
Another important development for vehicle infotainment systems will be the integration with driver assistance systems to
utilize common processing requirements and to harmonize the vehicle’s user interface. This will raise completely new requirements for the MOST standard in the area of fault-tolerance.
[1] ESG Cooperation: ESG MSC Editor, URL: http://www.esg.de/
leistungen/automotive/bausteine, Last visited: Aug. 2008.
[2] Fujitsu Cooperation: MB86R01 Data Sheet, Version 1.3, URL:
www.fujitsu.com, Feb. 2008.
[3] MOST Cooperation: Automotive Application Recommendation
for Optical MOST Interfaces, Version 1.0,
URL: www.mostcooperation.com, Dec. 2003.
[4] MOST Cooperation: MOST Specification, Rev. 3.0,
URL: www.mostcooperation.com, Jun. 2008.
[5] MOST Cooperation: MOST150 Enables Efficient Transport of Video Streams and IP-Based Packet Data, Press Release,
URL: www.mostcooperation.com, Oct. 2007.
[6] MOST Cooperation: MOST MSC Cookbook, Rev. 1.2, URL:
www.mostcooperation.com,
Apr. 2005.
[7] SMSC Cooperation: MOST NetServices Layer I; Wrapper for
INIC; V2.1.x, User Manual Specification,
URL: www.smsc-ais.com, Jul. 2008.
[8] SMSC Cooperation: OS8104 – MOST Network Transceiver, Final
Product Data Sheet,
URL: www.smsc-ais.com, Jan. 2003.
[9] SMSC Cooperation: OS81050 – MOST Network Transceiver,
Data Sheet, URL: www.smsc-ais.com, Aug. 2007.
[10] SMSC Cooperation: OS85650 – I/O Companion Chip, Data
Sheet, May 2008.
22
CONTACT
References
Daimler AG
HPC: 059-X908
71059 Sindelfingen
Germany
T +49 7031 90 48890
E alexander.leonhardi@daimler.com
FORUM
MO S T N ETW ORK I N G AND SYSTEM ARCHITECTURE
MOST150 – The New Generation of the
Infotainment Backbone
Media Oriented Systems Transport (MOST) has become the de facto industry standard for automotive infotainment systems.
Since its introduction in 2001 its use has become widespread. At the same time new technical developments have been
taking place. The emphasis has been on the robustness of the system, cost reduction, video transmission and cost-effective
transport of data intensive services, as well as increases in bandwidth. This article gives an overview of the recent developments of the widely used MOST backbone, used in many of today’s vehicles, and includes details of the new generation
running at 150 Mbps.
MOST – The Backbone of the Infotainment System in the Vehicle
The first generation of MOST ran at 25 Mbps and is now on the
road around the world in over 45 vehicle models from many car
manufacturers. It serves as the communication backbone of the infotainment systems of all these automobiles. MOST25 uses a fiber
optic (POF) physical layer to transport its data. In late 2007, the first
vehicles have been launched in Japan, applying the second generation of the MOST Technology that uses unshielded twisted pair
(UTP) copper wires at an increased bandwidth of 50 Mbps. MOST
has undergone extensive enhancements, not only technologically
but also in the areas of robustness and ease of use, cost reduction,
and bandwidth increases, as discussed below.
[Fig.1 ]
Intelligent Network Interface Controller (INIC) and System Software
The INIC constitutes a complete MOST node. It does not need any interaction with an application to operate the network. This
allows for the node to come on the network quickly even if the application needs longer to start up. The application registers
with the network when it is ready. If the application stops responding, the INIC goes into protected mode and continues
managing the node on its own. Any application issues are locally encapsulated and do not affect the rest of the system. The
INIC API is all the application needs to connect with the MOST network.
The specifications have been continuously refined in the working groups of the MOST Cooperation to remove ambiguities
and add clarity. NetServices, the driver stack for MOST provided by SMSC, is running in many different platforms with a wide
range of characteristics and performance capabilities. NetServices has been expanded and enhanced to make it easier to port
to different processor- and software architectures. The MOST System Management Module (MSMM), a new module from
SMSC, implements the necessary master function to manage a network. This critical function, that usually sits in a head unit
and controls the whole MOST network, no longer needs to be independently developed by each Tier1 supplier.
23
30TH SEPTEMBER 2008
STUTTGART - GERMANY
INIC chips are available from SMSC for every speed grade of the
MOST network. The NetServices provides a complete abstraction of
the physical layer - and thus the application layers above will operate which each speed grade of the network. There are now powerful tools available for network analysis and compliance verification
that cover most aspects of development, production and quality
assurance of MOST components.
Cost Reduction
As the market has grown, the cost of a MOST node has been roughly cut in half. However, like with any new technology, there is still
some room for further cost reductions. One important area is the
optical interface, which in the early days did account for about two
thirds of the cost of a MOST interface.
[Fig.2 ]
Each MOST node requires additional peripheral functions in addition to the optics and the network IC. For example, there
are voltage regulators, a wake-up interface, diagnostic lines, etc. These system functions are integrated into so-called MOST
power supply ICs available from SMSC or ST Microelectronics, which help reducing the peripheral cost for implementing
MOST interfaces. Another example is a MOST companions IC from SMSC which enables very powerful signal distribution
inside a MOST ECU, as well as the DTCP encryption/decryption of streaming audio/video data.
Bandwidth and more – the everlasting discussion
Whenever a network is defined for whatever application, the discussion about bandwidth comes up. And in general, the specified data
rate never is sufficient for all corner cases. But the decision about
the network bandwidth deals with many different parameters. One
extraordinarily important one is cost, another one the availability of
mature integrated system components for the system implementation. In the definition phase of the first generation of MOST about
10 years ago, other competing network solutions were advertising
much higher data rates like S100 or S200, but other important system components were missing. To make a long story short, there
is always a sweet spot for the bandwidth when all relevant system
components are considered.
[Fig.3 ]
The infotainment systems in vehicles are constantly becoming more
powerful. New functions are integrated that place higher requirements on the network. For example, hard disks are being introduced into the car, navigation shall be accessible from the rear seats, multiple SD and HD streams from either mass storage
media, digital broadcast services or portable consumer devices need to be transported. At the same time, more and more IP
based communication is introduced and seamless data routing from portable consumer devices but also for SW download
and On-Board-Diagnosis (OBD) features.
Portable Media, Portable Consumer Devices and Broadcast Media, all these media have one thing in common: They provide
video content only in compressed format. Therefore, an important question to be asked is: How much video transport capacity is really needed, and at which price? Is it really useful to make the MOST interface in – let’s say – an audio amplifier more
24
FORUM
expensive to support a comparatively low percentage of ultra-highperformance headunit applications?
Considering the fact that increasingly wireless media are also part of
the system, the question of an appropriate protocol support becomes more and more important. Today, we have very often Bluetooth
connections to the cellphone. In some cases, wireless headphones,
either using BT, too or some proprietary standard, are applied. New
device like, IPod, I-Phone, I-TV or an increasing number of PDAs
or PNDs are supporting WLAN, too. Some car manufacturers even
consider the use of PDAs or UMPCs as extentions to their OEM
systems, e.g. to integrate an after sales PND unit instead of an OEM
navigation system or, using wireless rear seat entertainment devices.
[Fig.4 ]
In such cases, it is highly desirable that the end-to-end transport of
the respective content (A/V streaming data or navigation content) can be handled by the backbone network without complicated and expensive buffering, re-packetizing, address handling etc. At the same time, the data transport is required to be
secured in order to fulfill all the existing copy protection requirements of the respective license administration organizations
and content owners. Ideally, the content protection will be part of the network channel itself – completely transparent to the
application and without additional handling overhead.
Besides Infotainment, other functions and features requirements are becoming increasingly important, too:
On-Board-Diagnosis is in its transition phase to be Ethernet / IP based. The SAE standardization foresees a global transition
within about the next decade.
And, last but not least, the infotainment system gains more and more features coming from other applications, e.g, driver
assistance. Those features might consist of relatively simple things like rear-view cameras, but will evolve to more advanced
applications like traffic sign recognition, lane assistance or advanced telematics services which reach up to car-to-car communication. Most of the driver assist features are very heavily depending on real-time data transport – even much more than
classical infotainment applications. Here, a synchronous backbone provides the optimum solution for future-proof architectures and applications.
MOST150 offers a whole multitude of solutions. Starting with its synchronous nature which becomes increasingly important,
continued with a variety of new data transport mechanisms offering seamless and high-efficient end-to-end data transport of
all relevant protocols, reaching to the built-in DTCP content protection, it does offer the ut-MOST flexibility right in the sweet
spot for the data rate of today and the near future.
MOST150 - Bandwidth and Physical Layer
As discussed, MOST150 offers a bandwidth of 150 Mbps. It is designed and optimized for using the same POF based physical
layer as the first generation MOST, for good reasons:
First of all, the discussion about weight is, interestingly, more modern than ever. In times where the vehicle industry is heavily
driven by reducing fuel consumption and CO2 emission, every single gramm counts in reducing the vehicle’s weight. And an
optical fiber weighs less than a copper cable, in particular when we talk about shielded cables.
Secondly, we discussed the increasing number of wirless services and standards: Bluetooth, UWB, UMTS, LTE, WLAN, and so
on. The performance of these wireless services and their quality of service is heavily depending on the EMC conditions of the
environment. And considering the constantly reduced requirements for electromagnetic emissions of equipment in the car,
25
30TH SEPTEMBER 2008
STUTTGART - GERMANY
what can be better than an optical physical layer, which is emission-free by nature?
And thirdly, offering a smooth transition from one generation to the next one for all those car companies who have been
using MOST already for many years, is highly beneficial.
The 150 Mbps data rate allows use of the existing physical layer. LED development has also advanced to the point where
these cost-effective light sources can be used at 150 Mbps, instead of the more expensive VCSELs and RCLEDs. Current
POF based cable harnesses, connectors, protection systems, assembly processes, etc, don’t have to be changed. MOST150
provides for gradual evolution.
MOST150 – The multiplexed network
MOST25 and MOST50 provide a control channel for real-time control of devices; a packet channel for the transport of data
services; and, most importantly, a synchronous domain in which synchronous audio and video channels can be instantiated.
MOST150 also offers all these channels, but with significant enhancements. The bandwidth of the control channel was
doubled. In addition, the payload was increased so larger packets can be transmitted without segmentation. Pre-emptive acknowledgement for both the control as well as the packet
channel provides a mechanism to avoid sending of messages that
the receiver knows it cannot accept. This increases channel capacity
and reduces the re-transmission of messages, and thus increases
the transport efficiency significantly, even compared to other packet
switched networks, e.g. standard 100baseT Ethernet.
Compared to the first generation MOST, the synchronous domain
was not changed much. However, its size can be changed dynamically during runtime to match current needs. Bandwidth not currently used by synchronous channels is available for packet transport.
Additionally, MOST150 offers two additional channels: Ethernet
and an isochronous.
From a high-level view MOST150 is a multiplexed network that includes the current MOST with double bandwidth as well as 10/100 Ethernet (see figure 5).
[Fig.5 ]
MOST150 – Transparent Ethernet Channel
The new channel added to MOST150 can transport unmodified
Ethernet frames used by consumer products. It supports addressing
using MAC addresses. It presents itself to applications as if it were
Ethernet – completey transparent. TCP/IP stacks and other Ethernet
communication protocols, like e.g. Appletalk, UPNP, etc., can communicate over MOST without changes. MOST150 is therefore the
automotive-ready physical layer for Ethernet in the car.
[Fig.6 ]
MOST150 - Isochronous Transport
MOST guarantees Quality of Service (QoS) to streaming data by reserving a dedicated channel. This is how synchronous data
is handled. However, some streams cannot be cost-effectively synchronized to MOST. Increasingly streams use bursts (for example MPEG Video) or streams of packets (IP Video). MOST offers three isochronous mechanisms to support these streams:
26
FORUM
1) A/V packetized isochronous streaming:
This mechanism, formerly also called ‘burstmode streaming’ or ‘packetized isochronous’ allows the transport of streams
where each time unit has different amounts of data – they are bursty. Examples include MPEG streams such as the ones
from DVD/BD players or DVB Services. The maximum bandwidth is reserved. Arriving data are written to a frame buffer that
is periodically sent on. There is a mechanism to identify the current
payload of each isochronous frame.
In addition, the Transport Stream Interface (TSI) has become a standard among video processing ICs. The MOST150 INIC supports multiple TSIs so that video ICs can be directly connected to MOST. No
expensive glue logic is required anymore. For example, a DVB-T tuner or an MPEG encoder attached to an existing analog tuner could
be connected directly to a MOST150 INIC.
2) DiscreteFrame Isochronous streaming:
Often streams are synchronous (constant amounts of data per unit
of time) but not synchronized to MOST. An example would be the
transport of a 48 kHz audio stream over MOST with a 44.1 kHz
[Fig.7 ]
frame rate. DiscreteFrame Isochronous transport (formerly also named Constant Rate Streaming) named as allows tunneling
of such signals without having to synchronize them with MOST. Every MOST150 INIC has inputs for frame clocks. The clock
signal is measured and reconstructed after transport.Thus, even clock signals can be tunneled, allowing the remote synchronization of devices to non MOST related clock signals, e.g. for a 48 kHz I2S signal to be transparently tunneled over MOST at
44.1 kHz or a 27 MHz Video clock.
3.) QoS IP streaming:
There are streams broken into packets that have to be transported with high QoS. Two examples are Voice over IP and Video
over IP. These could be transported over the Ethernet channel. However, a private isochronous channel could alternatively
be reserved for them. The QoS IP streaming (Packet streaming, QoS isochronous) mechanism of MOST supports packets and
with them high QoS movement of streams of packets. These packets are transported without addressing information so a
transmission to several receivers does not require extra bandwidth.
Conclusion
CONTACT
MOST is already the de-facto standard of the automotive industry for distributing infotainment information around a vehicle.
These latest developments make it an even more attractive solution for a variety of A/V applications both inside and outside
the car. MOST provides a cost-effective backbone with high data rates, a variety of physical layers and a simple architecture
for scalability to different speed grades. It can transparently transport IP
traffic with a robust infrastructure already proven under the stringent
EMC, environmental, quality and robustness requirements of the autoHarald Schöpp
SMSC Europe GmbH
motive world. Even an extention of application areas beyond infotainBannwaldallee 48
ment applications is within the range now.
76185 Karlsruhe
Germany
T +49 721 625 37 0
F +49 721 625 37 119
E ais@SMSC.com
W www.smsc-ais.com
27
30TH SEPTEMBER 2008
STUTTGART - GERMANY
MOST Simulation Framework
Richard Wurm, University of Applied Sciences
Deggendorf
Abstract: “High-speed” in-vehicle communication systems, especially audio and video solutions, have received considerable
research attention within the last few years in the automotive industry. Such research is largely driven by customer demand
for the integration of an increasing number of consumer electronic devices into the car. In addition, there is a rapidly growing
requirement for in-vehicle real-time audio and video based driver assistance systems. Current solutions, partly implemented
as overlay networks to the real infotainment network, are costly and inflexible. The emerging third generation of automotive
networks promises enhanced functionality to meet market demands, providing good solutions for audio and video streaming
by supporting additional IP based data communications. This paper presents an overview on a MOST Simulation Framework
resulting from BMW’s activities on investigations into a future infotainment network.
1. Introduction
In recent years there has been a significant growth in demand for driver assist systems, to support vehicle applications. Common representatives examples of such systems include real-time cameras and multimedia systems. Furthermore there is a
rapidly growing demand for integration of consumer electronic devices into the car. Thus, automotive infotainment systems
have to provide improved performance to support high bandwidth media quality, with low delay and jitter specifications.
Current in-car communication systems, such as MOST25 [1] and CAN [2] networks, have already reached their capacity
bounds. Hence overlay networks, in form of several point-to-point connections, are being integrated into the car. As a result,
the in-vehicle A/V (Audio/Video) interconnected system has become inflexible, complex and costly. Furthermore, there is
a rising increase in the complexity of the on-board communication systems, as individual transmission systems often use
separate protocols.
In order to solve such issues, a new in-vehicle network architecture for audio and video transmission flows, based on the third
generation of MOST [1] [5] is proposed. The solution also considers employing the Internet Protocol (IP) as an abstraction layer
between the transmission system and its applications [4]. However, it is important to note that any analysis considerations do
not extend to include the transport of time-critical and safety-critical data, as it is assumed that such data will be transmitted
on separate specialized serial deterministic, fault tolerant bus systems, e.g. FlexRay.
In-vehicle network traffic can be divided, according to Rhamani et al [3], into four traffic groups, labelled as follows: 1) ‘hard
real-time’; 2) ‘soft real-time’; 3) ‘multimedia’; and 4) ‘best effort’. The work in this paper is mainly focused on the transmission of ‘soft real-time’ data and ‘multimedia’ information, while ‘hard real-time’ traffic and ‘best effort’ traffic are taken into
consideration as interfering traffic only, to model a worst-case transmission scenario in the analysis. In the following sections,
the stated traffic groups are statistically modelled for simulation. The OMNeT++ [7] simulation environment is presented,
followed by a description of the adjustments made to provide MOST-like functionality within the simulation framework.
2. Traffic modelling
An in-vehicle convergence network has to support various types of data. For an appropriate network design it is necessary to understand the nature of the traffic data so that simulation models can be developed. Some important data categories are as follows:
28
FORUM
I) Audio Data
Inside the vehicle, several types of audio data are transmitted for the entertainment of the occupants, provided by sources
such as CD or MP3 players. In addition audio for safety reasons, e.g. PDC (Parking Distance Control) or emergency call, is
transmitted by specific ECUs. The resulting data rate distribution can be constant. In the case of VoIP, the data rate amounts
to 64 kBit/s over the entire call duration.
II) Video Data
In-vehicle video sources are either entertainment sources, such as DVD players and TV tuners, or real-time camera systems
employed by driver assistance services. In each case, video is coded with a variable bit rate (VBR).
III) Control Data
There are several flavours of bus systems for control and measurement functions in a vehicle. The most common examples
are K-CAN and PT-CAN which are specified with a data rate of up to 500MBit/s. On Ethernet, such control data would be
transferred as 64 byte packets at data rates of up to 4 MBit/s, over the entire transmission time. This is the same for MOST25
Control Channel Messages providing a data rate of about 705.6 kBit/s@44.1 kHz. Data flows are modelled by CBR (Constant
Bit Rate) applications, meaning that all packets have the same size and are transmitted with a constant time interval.
3. OMNeT++ Simulation Environment description
OMNeT++ is a tool that represents a discrete event simulation environment [7], for the simulation of communication networks. The
generic and flexible architecture supports the simulation of complex
IT systems and hardware architectures. Thus the tool is well suited
for the simulation of a MOST network.
OMNeT++ provides a component architecture for the simulation
models. The components, called modules, are programmed in the
C++ programming language. For the assembly of modules into larger components and models, a high-level language (NED) is used.
Furthermore, OMNeT++ provides extensive GUI (Graphical User Interface) support. The OMNeT++ modular structure, has a simulation
kernel as well as other models that can be embedded easily into
specific applications.
The MOST-enabled OMNeT++ Simulation Framework can now be
described. All MOST devices are mapped as generic Ethernet devices, whereby any device has its own parameter file. The ring topology, presented in Figure 1, is set-up by *.ned files.
[Fig.1 ]
Figure 1: General build up of a MOST ring in OMNeT++ as described
by a *.ned files.
The *.ned files in turn describe the build-up of the modules, including all inputs, parameters, connections with delays, bit error rate
(BER) and transmission rate. In doing so, this results in the general
configuration of a MOST150 device, as presented in Figure 2.
Figure 2: General build up of a MOST device in OMNeT++ as described by a *.ned file.
[Fig.2 ]
29
30TH SEPTEMBER 2008
STUTTGART - GERMANY
Here, ‘rxtx’ represents the MOST INIC receiving and transmitting frames from/to the bus. Control (ctrl), synchronous (sync),
asynchronous (async) and MOST / Ethernet packet data (mep) thereby provide the interfaces to the applications in the simulation environment.
For an incoming MOST frame at the INIC, the ‘rxtx’ unit forwards that message to the respective application via the specific interfaces. The unit thereby monitors the free space in the MOST frame. In turn any application is triggered by the ‘rxtx’ module
for data to send, and if a send is required, the recently available bandwidth in the MOST frame is notified to the application
in order to send the adequate sum of data.
As the MOST Ethernet packet channel, requires that all data are transmitted in a token manner, a special mechanism is implemented in the ‘mep’ unit to calculate if a device has the token or not. If so, the device is allowed to send, indicated by
the writing “ACTIVE”, data from the Ethernet application on the MOST/Ethernet packet channel. Hence, a kind of quality of
service mechanism is thus implemented.
Because of the modular structure of OMNeT++, the Ethernet application connected with the ‘mep’ unit via ‘meprx’ and
‘meptx’ can be taken from the OMNeT++ INET Framework [6] without any changes.
5. Conclusion and future work
In this paper the main concerns of the current in-vehicle audio and video transmission systems have been introduced. A
network architecture based on MOST150, with the use of IP communciation, is suggested to address certain issues. Further,
an implementation of a MOST150 Simulation Framework was presented to allow a network simulation prior to system development. In the furture work performance analysis will be carried using the MOST Simulation Framework for measuring
some QoS parameters.
6. References
30
M. Eng. Andreas Schramm
BMW Group
Max-Diamand-Strasse 13
80788 Munich
Germany
T +49 89 382 57718
F +49 89 382 49163
E andreas.as.schramm@bmw.de
Dr. Donal Heffernan
Department of Electronic &
Computer Engineering
Ireland
E donal.heffernan@ul.ie
CONTACT
[1] MOST Media Oriented Systems Transport, Rev. 2.5, MOST Cooperation 10/2006. Available: www.mostcooperation.com//Specifications_Organizational_Procedures/index.html
[2] CAN Specification, Version 2.0, Robert Bosch GmbH, 1991.
Available: www..semiconductors.bosch.de/pdf/ can2spec.pdf
[3] M. Rahmani, J. Hillebrand, W. Hintermaier, E. Steinbach and R.
Bogenberger, ”A novel network acrhitecture for in-vehicle audio
and video communication”, IEEE Broadband Convergence Networks
Workshop, Munich, Germany, May 2007
[4] A. Schramm, D. Heffernan, “Analysis of a Synchronous Optical
Network for In-vehicle Audio and Video Communication”, Applied
Electronics Conference 2008. Pilsen, Czech Republic. Sept. 2008.
[5] A. Schramm, D. Heffernan, “MOST Generation III – Primed for
the Future!”, Automotive Electronics Symposium - 2007.
TAE: Technische Akademie in Esslingen, Germany. Dec. 2007.
[6] OMNeT++ Community, ”INET Framework”,
Available: www.omnetpp.org.
[7] OMNeT++ Community, ”OMNet++ simulator”,
Available: www.omnetpp.org.
Richard Wurm
Edlmairstrasse 6+8
94469 Deggendorf
Germany
E richard.wurm@stud.fh-deggendorf.de
FORUM
Proposal for a MOST150/
Ethernet Gateway
Abstract: A proposal is presented for a MOST150/Ethernet Gateway for IP (Internet Protocol) communication with guaranteed QoS (Quality of service), based on some investigation results for timing analysis for MOST150. A brief introduction
to QoS, QoS management and traffic classification is presented. With the fast adoption of IP-based communication for
computing, and mobile computing as well, users are expecting a similar service in wired and wireless networks. This raises the
need for setting guarantees for the quality of the offered services (QoS). The issues are of strategic interest to the automotive
industry, where research is ongoing for a future “high-speed” in-vehicle infotainment network, which can handle the users’
demands for bandwidth and quality. To date various solutions are emerging for the interconnection of individual in-vehicle
infotainment devices using different types of automotive networks. A key question is how to address the interoperability
issues for different devices and networks. In this paper a new, in-vehicle network architecture is investigated employing the
Internet Protocol (IP) as an abstraction layer between the transmission system and its applications. The work is based on third
generation of the MOST [1] technology, promising functionality in providing good solutions for IP data transfer as well as IP
data streaming.
1. Introduction
Recent years have seen a change of emphasis on the use of electronic entertainment equipment. The home network is
becoming the ‘media hub’ of the house. The Consumer Electronics (CE) industry is developing new devices that can tap into
the network for easy data access. Broadband providers are deploying many new services, such as IPTV and VoIP, to support
the market. The introduction of wireless technologies, such as IEEE 802.11 (WLAN), has helped to fuel the growth of the CE
industry.
The telecom industry, in recent years, has developed enhanced communication solutions, particularly in the wireless sector,
that can enhance access to the Internet [6]. Such solutions include the General Packet Radio Service (GPRS), Enhanced Data
Rate for GSM Evolution (EDGE), Universal Mobile Telecommunications Systems (UMTS) and International Mobile Telecommunications (IMT-2000). These technologies are able to carry IP packets using a packet switching network parallel to the voice
network.
The automotive infotainment market now expects many of the CE entertainment devices and communication services to be
available within the vehicle. Services such as IPTV and VoIP will be demanded from the infotainment system of a future vehicle.
More flexible mobile computing interfaces, wired and wireless, for data management and data streaming will certainly be
demanded.
However, the automotive requirements are much more complex, as there are parallel demands for driver assist systems, to
support applications such as real-time cameras and other multimedia systems. A high-performance in-vehicle infotainment
architecture is required, to support high-bandwidth, high media quality, with low delay and jitter specifications.
31
30TH SEPTEMBER 2008
STUTTGART - GERMANY
Current in-vehicle network systems, such as MOST25 [1] and CAN [2] networks, have already reached their capacity limits,
and are too inflexible and complex for emerging demands. The third generation of MOST [1] defines a new in-vehicle network
architecture for audio, video and data transmission. The authors have proposed enhancements in [4] where the solution also
considers employing the Internet Protocol (IP) which facilitates the design of applications and services independent of the
environment in which they will operate.
By taking the third generation of MOST [1] as the future automotive infotainment network, this paper proposes a concept
for a QoS-enabled gateway based on the timing analysis given in [4], to suggest a proposed architecture of a MOST/Ethernet
gateway, supporting QoS functionality for IP data communication.
2. What is QoS?
In general, QoS (Quality of Service) is a concept whereby transmission rates, error rates, and other system characteristics can
be measured, improved, and to some extent guaranteed in advance. QoS is of particular interest for the continuous transmission of high-bandwidth video and multimedia information. QoS attempts to guarantee for an application the resources
required to meet the necessary network performance attributes to effectively serve end users. From an end user’s perspective,
QoS is determined by the characteristics of service delivery that impact most critically on his/ perception of the service.
Furthermore, QoS enables a network to deliver classes of services (CoS), specifying different prioritized treatments for
different services, or for different groups of users. QoS allocates network resources according to the requirements, while CoS
provides prioritized allocation of network resources without guaranteeing specific measurable traffic quality characteristics.
CoS is implied in a QoS policy associated with a subscriber. The network uses CoS to provide different QoS treatments to
different services, subscribed to by different users, i.e. the network uses CoS for service and user differentiation.
3. QoS Management and Traffic Classification
The Telecomm/Internet world is aware of the need for service classification. Hence, QoS technologies are developed by the
IETF, providing different levels of services to IP flows. According to their fundamental operation, the IETF architectures can
be classified into two types as follows: The first approach is the Integrated Service (IntServ) framework providing explicit endto-end reservations for applications by choosing between multiple levels of service. IntServ defines three classes of service:
1) guaranteed load, 2) control load and 3) best effort. The service is defined by the resource reservation protocol (RSVP).
Differentiated Services (DiffServ) is IETF’s second attempt to support QoS. In comparison to the IntServ, which provides perflow guarantees, DiffServ’s philosophy is based on mapping multiple flows into a few service levels. That approach is sometimes referred to as CoS.
In this paper the authors are concerned with a novel QoS enabled MOST/Ethernet gateway. Before any QoS management and
bandwidth allocation can be performed, the Gateway must identify the traffic traveling through it. Hence, a so-called traffic
classification process is required. According to Hwang/Tseng et al [3], eight types of traffic classes are proposed as follows:
• Security traffic – includes security applications. Hence a relatively small bandwidth but high priority channel should be
reserved.
• Multimedia traffic – includes digital video streaming (IPTV) as well as VoIP applications. Large bandwidth, small delay and
jitter are required for this class. Thus, high priority should be given to this class. Bandwidth is proposed to be reserved at
runtime of the application.
• Control traffic – belongs to any kind of control signals. This class is noted for small and short messages and is assigned
with high priority but with no bandwidth reservation requirement.
• ICMP traffic – includes ping traffic as well as feedback messages about problems and errors in the communication
environment. The priority thereby depends on user requirements.
32
FORUM
• FTP traffic – belongs to any kind of file transfer. Significant for that class, a large throughput is.
However it is not sensitive to delay and jitter. File transfer is suggested to be suppressed if coexisting with higher priority traffic.
• Web traffic – includes normal web browsing. As active user interaction is involved in that class, it should not be
disregarded. Although the priority is assigned to be not as important, a fair portion of bandwidth should be reserved.
• Interactive traffic – belongs to delay sensitive traffic of an application (e.g. telnet). Thus, it should be transmitted with
minimum delay in regard to their sensitivity to Round Trip Time (RTT)
• Best effort – belongs to any kind of data transmitted with best effort only.
4. QoS Enabled Gateway architecture
As a basis for the concept of the QoS-enabled MOST/Ethernet gateway, a short overview on the third generation of the MOST
technology [5] is presented. MOST150 defines 4 channels with individual QoS performance. Assuming a pure in-vehicle IP
data communication in the future, the gateway solution is mainly focused on the two channel types which are able to transport Ethernet packet data: the Isochronous channel and the MEP (MOST Ethernet Packet) channel.
Isochronous Channel: Processes on isochronous channels require proper timing coordination for transmission applications
such as voice and digital video streams. The isochronous data transfer ensures that data flows continuously and the sink
receives the data, at a steady rate. Since the isochronous channel is a subset of the synchronous channel, it offers best QoS
parameters for delay, jitter and packet loss [4]. As the channel also supports the transmission of Ethernet telegrams (IEEE
802.3, IEEE 802.3ac) its use is proposed for multimedia traffic data. IntServ and RSVP also can be applied to the Isochronous
channel as it provides a unidirectional end-to-end link with a certain amount of bandwidth reserved. The allocation mechanism on MOST thereby is quite similar to that within RSVP.
Packet Channel: The MEP (MOST Ethernet Packet) channel is shared within the whole network. If the channel
is free, devices are allowed to send their data immediately. However in case a data transmission on the MEP is
ongoing and a device wants to have the permission for
sending, channel access is managed in a token manner.
The device that holds the token is allowed to send. Prioritization is achieved by the token mechanism such that
a MOST INIC can be configured to let the token pass for
some time before sending upcoming Ethernet data packets. Thus 16 priority values can be adjusted dynamically
via the MOST Network Services, which means that each
Figure 1: Architecture of a QoS-enabled MOST/Ethernet Gateway
message type can be assigned a certain priority at runtime. Hence, the MEP is ideal for supporting the DiffServ QoS management service. The DiffServ-QoS service architecture of
the proposed MOST/Ethernet Gateway is based on a simple model where Ethernet traffic entering the gateway is classified
and then conditioned before sending it onto the MOST network.
Figure 1 illustrates the proposed architecture of a MOST/Ethernet gateway supporting QoS functionality for IP data communication. IntServ, RSVP as well as DiffServ are managed by the Broker. The incoming data packets are processed by the Dispatcher, distributing them to either the Isochronous channel or the MEP, respectively. Thus, in case of DiffServ, an assignment of
the Ethernet packet priorities to the MOST MEP priorities is proposed, as listed in Table 1.
33
30TH SEPTEMBER 2008
STUTTGART - GERMANY
Traffic class
DiffServ setting
MEP priority
Security
EF
0
Web
AF22
5
File transfer
AF32, AF33
6, 7
Interactive
AF21
3
Multimedia
AF11
1 (audio), 2 (video)
ICMP
BE
14
Best effort
BE
15
Table 1: DiffServ-QoS mapping onto MEP priority
Hence the Broker of the MOST/Ethernet Gateway even performs functionality like a DiffServ router.
5. Conclusion and future work
In this paper an introduction to emerging IP-based in-vehicle use cases has been presented. After a short discussion of QoS
and QoS management, based on the IETF classifications, an overview on traffic classes for QoS-aware gateways was presented.
A concept for a MOST/Ethernet Gateway architecture was proposed, which supports QoS features of the Ethernet-capable
MOST channels. Finally, a proposal for the mapping of DiffServ-QoS parameters onto the MEP priorities was presented.
34
CONTACT
[1] MOST Media Oriented Systems Transport, Rev. 2.5, MOST Cooperation
10/2006. Available: www.mostcooperation.com//Specifications_Organizational_Procedures/index.html
[2] CAN Specification, Version 2.0, Robert Bosch GmbH, 1991. Available:
www..semiconductors.bosch.de/pdf/ can2spec.pdf
[3] W. Hwang, P. Tseng, “A QoS-aware Residential Gateway with Bandwidth Management”, IEEE Transactions on Consumer Electronics, Vol. 51,
August 2003
[4] A. Schramm, D. Heffernan, “Analysis of a synchronous Optical Network
for In-vehicle Audio and Video Communication”, Applied Electronics 2008,
Pilsen, Czech Republic, Sept.. 2008.
[5] A. Schramm, D. Heffernan, “MOST Generation III – Primed for the Future!”, Automotive Electronics Symposium - 2007. TAE: Technische Akademie in Esslingen, Germany. Dec. 2007.
[6] J. Manner, A. Lopez, A. Mihailovic, H. Velayos, E. Hepworth, Y.Khouaja,
“Evaluation of Mobility and QoS Interaction”, online: http://www.cs.helsinki.
fi/ u/jmanner/papers/ComNet-preprint.pdf
[10] S. Kumar, M. Huang, “Quality of Service in UMTS Wireless Networks”,
Bell Labs Technical Journal 7 (2), 2002
CONTACT
6. References
M. Eng. Andreas Schramm
BMW Group
Max-Diamand-Strasse 13
80788 Munich
Germany
T +49 89 382 57718
F +49 89 382 49163
E andreas.as.schramm@bmw.de
Dr. Donal Heffernan
Department of Electronic &
Computer Engineering
Ireland
E donal.heffernan@ul.ie
FORUM
MO S T N ETW ORKI N G AND SYSTEM ARCHITECTURE
H.264 Low-latency Video
Compression in Automotive Applications
Dipl.-Ing. Ralf M. Schreier, On Demand Microelectronics
Controlling and optimizing the delay of real-time video compression systems has become a key issue for latency-sensitive
automotive applications. In MOST-bus environ¬ments, applications such as parking-aid cameras and multi-display distribution of computer-generated On-Screen Display (OSD) content and navigation system graphics require this key technology for
bandwidth-efficient implementations.
Whereas conventional implementations of video compression standards such as H.264 and MPEG-2 introduce significant latencies in the range of 500 ms, automotive applications usually require latencies significantly below 100 ms. Although video
compression standards provide the facility to signal a low-latency mode in the bitstream, the low-latency encoding and buffer
control are subject to the implementation and need to be tailored for specific applications. This paper explains the latency
sources in video compression systems and highlights the scope for application-specific optimization.
1. Introduction
Designing systems for low delay video transmission requires basic implementation knowledge as well as fundamental knowledge of the video codec algorithms and buffer management. As the standards only describe the algorithmic decoding procedure and profile features, the system designer has many options in selecting coding modes, coding parameters and buffer
sizes to meet the requirements of the specific target application.
The document first gives an introduction to the sources of latency in video compression systems caused by the codec architecture [1] and buffer require¬ments for transmission [2]. In the second part, the buffer latencies - which predominate - are
analyzed in more detail. Whereas the well-known intra-frame and inter-prediction (IP) coding modes can provide either good
coding efficiency or very low latency, an innovative intra refresh technique [3] is presented which allows optimization for
both critical parameters at the same time. Because video applications on the MOST-bus typically use a static, pre-allocated
transmission bandwidth, this paper focuses on constant bitrate (CBR) operating modes.
Selecting the coding parameters for low-delay applications is a trade-off between coding efficiency, limitations on rate fluctuations, re-synchronization capability
and computational requirements. For achieving low
buffer delays at CBR it is generally favorable to generate a constant amount of data in a short time interval
with minimum intrusion of a rate control algorithm. We
denote this time interval as frame-CBR or GOP-CBR according to the number of frames which are used for
Fig. 1: Compressed video transmission system delay sources
averaging rate variations, where a group of pictures
(GOP) denotes a sequence of an intra coded frame (I-frame) followed by predicted frames (P-frames).
35
30TH SEPTEMBER 2008
STUTTGART - GERMANY
2. Coding Mode Latency Analysis
A. System Delays
As illustrated in Fig. 1, the system latency of a compressed real-time video transmission comprises: algorithmic encoder latency; transmission latency; and algorithmic decoder latency. While the algorithmic latencies can be reduced by an optimized
implementation, the predominating transmission latency is directly related to the chosen coding mode. Due to the nature
of the video compression systems, latencies scale linearly with the
frame period Tframe which allows - in principle - a reduction of all
delays by increasing the frame rate at the cost of correspondingly
higher data rates.
Implementation-specific delays mainly depend on the selection of
the basic processing block size and the pipelining strategy of the
encoder and decoder. The reference codecs as well as many software based implementations use a frame-based processing scheme
which introduces large algorithmic delays. On the other hand,
hardware-optimized ASIC/FPGA implementations frequently use a
macroblock pipeline which reduces the on-chip memory requirements as well as delays. Due to the nature of continuous time video
sampling and system load balancing, we propose to use a row of
macroblocks similar to the MPEG 2 slice size as the basic processing
Fig. 2: Proportion of Intra-frame data (red) in a GOP of 12 frames
block. This results in small capture and processing delays of Dcap =
for H.264 video test sequences (CIF, no deblocking filter)
Dproc = Tslice ≈ 0.1 Tframe.
It should be noted that real-time video compression systems usually operate in a constant delay mode. Hence, the algorithmic
as well as the buffer delays are adjusted according to worst-case operating conditions and it is not possible to change the
delay during continuous operation.
B. Standard-mode CBR Latencies
Intra Coding Mode
The intra coding mode can achieve very low delays at the cost of a low coding efficiency. Dcap, Deproc and Ddproc can be
reduced to Tslice. As the intra coding mode generates approximately the same amount of data for each frame it is a safe
assumption to introduce a single Tframe buffer delay for the encoder and decoder buffers, which allows unrestricted distribution of data within each frame. Further reduction of the buffer delays is possible if the rate control algorithm limits the rate
variations within a frame to reasonable bounds. Video sequences with very unbalanced vertical texture (e.g. “flowergarden”)
require the largest encoder and decoder buffer delays up to Debuff + Ddbuff ≈ 0.8 Tframe. For the chosen operating point
and test sequences a data rate of 1.3 bpp (bits per pixel) is needed, which extrapolates to 12 Mbit/s for VGA resolution (YUV
4:2:0 color subsampling, 8 bit per sample, 30 fps). Consequently the intra-coding mode is well suited for applications where
minimum latency and high error robustness are the major concern.
IP Coding Mode
The predictive coding mode can achieve the same processing and capture delays as the intra coding mode, but the minimum
buffer delay is defined by the size ratio of the I-frame compared with the P-frames in the GOP. In order to achieve full image
quality at a constant bit rate, the additional data rate of the I-frame is averaged out over the following P-frames resulting in
a CBR interval of one GOP.
36
FORUM
In Fig. 2 the proportion of intra-frames in a GOP of 12 frames is shown for 10 video test sequences which are sorted by descending motion activity. Especially for video sequences with very limited motion, the data rate is concentrated in the I-frames,
resulting in minimum delays above 6 Tframe (NGOP = 12). Furthermore, for general-purpose video content with significant
scene changes, additional buffer latencies must be introduced for handling un-scheduled I-frames. For a GOP-size of 12 frames and the given test-set and quality (PSNR), IP-coding reduces the data rate by an average factor of 3.3 to 0.39 bpp (3.6
Mbit/s @ VGA) compared with intra-coding.
Due to the high latency requirements for CBR operation, IP-coding is generally not very suitable for low-latency applications.
However, in applications which allow several hundred milliseconds of latency (e.g. re-encoding of broadcast video), IP-coding
enables very good coding efficiency and good scene-cut handling.
IPB Coding Mode
The delay analysis of the bi-directional prediction modes (IBP) follows the IP coding mode analysis, with an additional frame
reordering delay of 2 Tframe (IBP-mode), and 3 Tframe (IBBP-mode). The buffer delays are quite similar to the IP coding mode.
These characteristics prohibit using the IPB coding modes in delay sensitive applications.
C. Intra Refresh Coding Mode Principle and CBR Latencies
In order to reduce transmission latencies, the video encoder should generate a constant data rate in a shorter time interval
than a GOP. The intra-refresh method is one enabling technology which reduces buffer delays by embedding intra-coded
regions in predicted frames as illustrated in Fig. 3. With the described principle, the large intra-coded frames of the IP-mode
can be eliminated, but at the same time the re-synchronization of the decoder can be guaranteed when a complete refresh
cycle is received. By applying additional optimizations, the coding efficiency of the predictive coding mode can be achieved
even in latency-critical camera applications.
The intra refresh can be combined with frame or GOP-level CBR operation. The frame CBR operation can achieve smaller
delays, but 9 % to 14 % additional data rate must be allocated on the average for large frames with high amounts of intracoded texture. This is caused by the fact that the amount of intra information can vary significantly within a refresh cycle. For
some critical video sequences (e.g. “foreman”, “flowergarden”), frames with more than 30 % overhead in data rate were
observed. Realistic delay bounds for the encoder and decoder buffers are Debuff + Ddbuff ≈ 0.8 .. 1.3 Tframe at 0.53 bpp data
rate ( ≈ 4.8 Mbit/s @ VGA). Increasing
the CBR interval to a whole GOP eliminates the overhead data rate of the
frame CBR mode at the cost of higher
buffer latencies. An analysis of 30 intra refresh strategies as proposed in
[3] indicates that buffers delays of Debuff + Ddbuff ≈ 1.5 .. 2.9 Tframe can
be achieved at an average data rate
of 0.47 bpp ( ≈ 4.3 MBit/s @ VGA)
for a guaranteed error recovery time
of 12 frames.
Fig. 3: Principle of a region based intra-refresh.
It can be concluded that the intra refresh method is especially useful in applications which tolerate maximum latencies in the
range of one to two frame periods and require high coding efficiency. Automotive target applications can include parking-aid
cameras as well as passenger monitoring, which are not as latency-critical as security-sensitive driver assistance systems.
37
30TH SEPTEMBER 2008
STUTTGART - GERMANY
3. Conclusions
In this paper the sources of latency in compressed video transmission systems were identified and described in the context
of automotive applications. In an optimized implementation, the largest delays are introduced by the encoder and decoder
stream buffers in CBR operation. It was shown that the standard coding modes can achieve either very low latency (intramode) or good coding efficiency (IP, IPB coding modes). To reduce the buffer latency of the IP-coding mode, the intra-frames
can be transmitted sequentially which guarantees complete error recovery after one complete refresh cycle. The basic intrarefresh technique can be optimized to enable low latency and good coding efficiency. With the described techniques the
appropriate coding modes can be selected for different applications, given the parameters target data rate, latency and error
recovery time.
38
CONTACT
[1] R. M. Schreier, A. M. T. I. Rahman, G. Krishnamurthy, A. Rothermel: “Architecture analysis for low-delay video coding”, IEEE Int.
Conf. on Multimedia and Expo (ICME), Toronto, July 9-12, 2006,
pp. 2053-2056.
[2] R. Schreier, A. Rothermel, “A Latency Analysis on H.264 Video
Transmission Systems”, IEEE Int. Conf. on Consumer Electronics
(ICCE), Las Vegas, Jan. 9-13, 2008.
[3] R. Schreier, A. Rothermel, “Motion adaptive intra refresh for the
H.264 video coding standard”, IEEE Tr. on Consumer Electronics,
Vol. 52, No. 1, Feb. 2006, pp. 249-253.
CONTACT
4. References
Dipl.-Ing. Ralf M. Schreier
On Demand Microelectronics
Donau-City-Strasse 11
1220 Vienna
Austria
E ralf.schreier@odmsemi.com
FORUM
MO S T N ETW ORKI N G AND SYSTEM ARCHITECTURE
Software Implementation
of MLB on the MPC5517
Jürgen Frank, Freescale
Abstract
This paper presents an alternative approach to Media Local Bus (MLB) implementation that is based on the Freescale MPC5517.
The MLB interface is created in a very cost effective manner, by using on-chip resources to emulate the functionality of the
interface. The approach has been named SoftMLB and uses the DSPI and DMA modules of the microcontroller with the IO
Processor (IOP) to implement the MLB protocol. All involved IP blocks and the software structure are explained within the
paper. The second part of this document describes the general software flow and how the dual-core system has to be set
up by the developer. Additionally an overview of the low level driver (LLD) structure is given. The LLD was developed within
Freescale and can be use to integrate the SoftMLB solution into the standard NetService stack. The paper concludes by
providing a summary detailing the advantages and limitations of the SoftMLB approach.
1. Introduction
MLB is the standard on-PCB bus between the microcontroller and MOST controller chips like the OS81050. MLB is able to
transmit all data and message types (synchronous, asynchronous and control), which are specified by the MOST standard.
Unfortunately standard microcontrollers do not directly support the MLB interface. This forces the system developers to
use an FPGA as a glue-logic between the MLB and the external bus of the microcontroller, which increases the system and
development cost significantly.
However, SoftMLB use the exiting peripheral modules of the MPC551x family to establish the connection, with a very small
glue-logic inside a CPLD. As a further cost reduction this glue logic has been integrated in MPC5517 MCU, which enables
the MCU to be directly connected - via level shifters - to the Media Local Bus.
2. The Media Local Bus
The physical layer of MLB supports three and five signal lines to transmit the data, but for further designs only the three signal
version should be use. SoftMLB supports both physical layer, but this text will be focus on the three pin interface, only.
The three pins are MLBDAT, MLBSIG and MLBCLK. MLBDAT and MLBSIG transmit their data in serial manner, starting with
the MSB. An MLBSIG value is 32 bit long and can be split in three elements:
• Command value (8 bit width):
This value is transmitted by the owner of a channel and informs the receivers about the data type (transmitted on MLBDAT)
and the position (begin, middle, end) inside the message stream. Transmission-break commands are also specified and used.
• RxStatus (8 bit width):
The RxStatus is transmitted by the receiver on the MLBSIG line and reflects errors cases of the transmission like a break
or a protocol error.
39
30TH SEPTEMBER 2008
STUTTGART - GERMANY
• Channel Address (16 bit width):
The channel address signs the logic channel which will transmit two frames later. This is an important fact and gives an MLB
implementation the time to prepare the internal state-machines for the right usage.
Graphic 2 1 shows the relationship between
the ChannelAddress and the other values
of the MLBSIG and MLBDAT line. MLBDAT
transmit the 32 bit user data which are parts
of a message, packet data or a stream.
For a detail description of the MLB protocol read the MLB specification [1] and the
OS81050 data sheet [2].
Graphic 2 1
3. The MPC551x-Family
The SoftMLB interface was implemented on the MPC5517, as this device is targeted at the automotive body and gateway
markets and offers all typical interfaces (e.g. LIN, CAN, FlexRay etc.). It also included the IOP which is essential for the emulation approach. By emulating the MLB interface it allows the MCU to be cost effectively connected to a MOST network
controller (OS81050), which is also attractive in the automotive entertainment markets.
The MPC5517 is a very reasonable dual-core chip which runs with up to 80 MHz and has an internal SRAM of 80 Kbytes. The
program memory size is 1.5 Mbytes.
Graphic 3 1 shows a block diagram of the MPC5517.
SoftMLB use the following modules of the MPC5517:
•
•
•
•
•
•
IOP (32-bit Power Arch. Book E VLE-only) core
MLB-glue logic
Two SPI interfaces
Several DMA channels
~ 2 Kbytes code size (FLASH)
~ 5 Kbytes data size for all data types (SRAM)
4. The data flow
The main task of the MLB-glue logic is to control the level shifters - if
need - and to route MLBSIG and MLBDAT data to the SPI interfaces
of the MPC5517. Both are driven with the MLB clock and works as
SPI slaves. Some additional signals like SPI-select and the IOP interrupt request are also generated by the glue-logic.
When the SPI shift register receives a new 16 bit value, this value
is transferred into the Rx-FIFOs. The FIFOs are able to initiate DMA
transfers, without any core support, to copy the values into the internal SRAM. With this system it is possible to store a complete MLB
cycle in the memory. An MLB cycle is a complete MLB dump of all
40
Graphic 3 1
Graphic 4 1
FORUM
physical channels; the 256FS mode supports eight channels.
The MLB glue-logic triggers the IOP via an interrupt request every 32 MLB clocks. Now, the IOP can execute the MLB protocol
and handle the input and output data.
5. The IOP program
When the IOP is in the IDLE state it’s execute an endless loop. The whole MLB protocol is handled inside the interrupt service
routine. The time to full fill this work can be directly calculated by the MLB clock.
ISR Time = (32 MLB cycle) - Interrupt Latency
In case the MLB clock is driven with 12.288MHz (256Fs) and the interrupt
latency is 250ns we calculate a maximum working time of 2350 ns. Together
with an average instruction time of 20ns it shows that the MLB stack has to be
implemented in a very efficient way. There is not the time to push and pop all
core registers on the stack and it’s not advisable to use a high level language
for the implementation.
For this reason we use assembler as the implementation language and for
e200z0 core VLE support is mandatory.
After the core enters the interrupt service routine, it loads the MLBSIG word
from the internal memory into a register. The next step is a receive-check
which copies the MLBDAT value, depending of the command value, into the
LLD queue, if needed. The correct address is known from the previous MLB
frames.
The rest of the code handles the channel address and setup the state-machine
for following MLB frames. In case a valid receive–channel address for control,
packet or synchronous data is received the correct buffer address is stored
into a core register to be prepared for the data receiving part two physical
channels later.
In case the system receives a valid transmit-channel address, it will check if
data are available for transmitting and pre-loads these data if needed. Additionally the right command value is pre-loaded. Both data pairs (MLBSIG and
MLBDAT) will be send out via the SPI interface on the MLB.
To improve the execution time, we use jump tables. An additional advantage
of this method is that our code generates constant execution timing, independently of the test value. This approach is used for the MLB command and
the channel address values. The table could be located in the volatile or nonvolatile memory.
The customer is able to configure the address-channel jump tables with
C-macros and functions which are delivered by Freescale together with the
complete software.
Graphic 5 1 shows the simplified flow diagram.
Graphic 5 1
41
30TH SEPTEMBER 2008
STUTTGART - GERMANY
6. NetService LLD integration
The goal was to create a complete software package, which
include the IOP code and the low level driver of the NetService stack, to simplify the integration in the customer’s
software structure. As it mention before the code is developed in VLE-assembler, unfortunately this instruction set
isn’t supported by all compilers suites (e.g. GNU gcc). For
this reasons the IOP code is delivered as a C-array which is
stored in the linker section vle_text. Variables are also stored in another linker section called vle_data. Both section
Linker file example - Code Fragment 6 1
locations could be controlled by the linker file.
The LLD functions itself use the standard header as it is
specified by the NetService stack and description in the documentation [3].
Additionally a demo implementation is included in the software package based on the open-source operating system eCos.
Customers have only to integrate their own NetService stack.
Finally, the complete code is compiled into a single image file for both cores. The functions to setup the IOP and the required
peripheral blocks in the right way are capsulated by the LLD functions.
7. Conclusion
The MPC5517, with SoftMLB implemented, can be connected to the MLB bus via level shifters with out additional hardware
like an FPGA. It supports both physical interface (3pin and 5pin) and the speed grade 256Fs. It offers a low cost solution for
[1] Media Local Bus Specification, Version 3.0
[2] Data Sheet OS81050
[3] MOST NetServices Layer I
42
CONTACT
8. References
Jürgen Frank, Sr. System Engineer
Freescale Halbleiter Deutschland GmbH
Schatzbogen 7
81829 München
Germany
E juergen.frank@freescale.com
FORUM
MO S T A N D OTH ER STANDARDS
Usage of AUTOSAR Diagnostic Modules in a MOST
Electronic Control Unit
Paul Hoser, BMW Car IT GmbH
Abstract: The AUTOSAR architecture is specified to provide drivers and services needed by automotive applications. Today’s
AUTOSAR architecture is primarily designed to fulfill the needs of applications from the body, chassis and power-train domain.
Unfortunately the AUTOSAR architecture lacks some features high-end infotainment Electronic Control Units (ECUs) require.
Among these is also the support for MOST. Thus, building a MOST-based high-end infotainment ECU with an AUTOSAR architecture is not an option. Nevertheless it is highly desirable to use some of the modules from the AUTOSAR architecture for
building high-end MOST ECUs. This saves a lot of development, testing and integration time.
Good examples for such AUTOSAR modules are all the modules realizing the diagnosis functionality. In order to use these modules on a MOST-based high-end infotainment ECU an AUTOSAR environment has to be emulated on the ECU. Within that
emulated AUTOSAR environment AUTOSAR’s Diagnostic Communication Manager (DCM), DEM Diagnostic Event Manager
(DEM), Runtime Environment (RTE) and a Central Diagnostic Software-Component can be executed. This brings standardized
diagnosis functionality from the AUTOSAR architecture to a MOST ECU.
This approach can be taken even further by extending the AUTOSAR emulation with an additional module which translates
MOST Function Block calls to AUTOSAR Virtual Function Bus (VFB) calls and vice versa. This enables AUTOSAR SoftwareComponents deployed on the RTE to communicate via the MOST ring with MOST Function Blocks (FBlocks). This allows the
integration of AUTOSAR Software-Components into the MOST-based ECU.
Keywords: AUTOSAR, MOST, Diagnosis, DCM, DEM
1. Motivation
For every vehicle there is a set of functionality specified which has to be provided by every ECU. Among those common functionalities there are such functions as handling remote request for updating the ECU’s software, configuring the ECU and
returning status data for the diagnosis of the ECU. Specification documents exist which describe these common functionality.
Usually this is done in plain text form using human language.
This informal way of specifying software functionality has proven to be very error prone. The chances that the implementation
from two developers of the same specification will behave in the same way are not very high. This makes the integration of
the ECUs into the vehicle a very difficult and time consuming task. Numerous iterations are needed until the ECUs provided
by different vendors behave in the same way. Vehicle manufacturers have reacted to this situation by providing their ECU suppliers with an implementation of a basic ECU architecture. This basic ECU architecture implements all the demanded common
functionalities of the ECU. This makes the integration of the ECUs easier for all involved parties.
2. AUTOSAR
In the last years the vehicle manufacturers, suppliers and tool vendors have taken the idea of a common basic ECU architecture a step further. They joined forces in the AUTOSAR partnership. The partnership’s goal is the specification of one common
43
30TH SEPTEMBER 2008
STUTTGART - GERMANY
basic ECU architecture which is to be used by all vehicle manufacturers. The specification of the AUTOSAR architecture has
matured over the last years. Numerous vehicle manufacturers have already begun with the migration of their basic ECU architecture implementation towards an AUTOSAR compliant implementation.
Today’s architecture specified by AUTOSAR provides drivers for automotive specific technologies and services needed by automotive applications. Unfortunately, it does not support all the features required by high-end infotainment ECUs.
Infotainment applications therefore are often built on general purpose operating systems like WinCE, Linux or QNX which
fulfill their needs. The drawback of using general purpose operating systems is that they lack automotive specific services.
From an integration point of view it would be desirable to reuse existing AUTOSAR implementations of these basic automotive services within high-end infotainment ECUs.
3. Architecture of the AUTOSAR Diagnosis
In this paper the AUTOSAR diagnosis functionality shall be used as an example to describe an approach for reusing existing
AUTOSAR modules and components in a high-end infotainment ECU.
The AUTOSAR architecture distinguishes between Basic Software (BSW) Modules and Software Components (SWCs).
The BSW Modules encapsulate the infrastructural functionalities and services of an ECU. The interfaces and behavior of the
BSW Modules are well specified by the AUTOSAR partnership.
Application functionality is to be implemented as a SWC. SWCs exceptionally communicate with each other and with BSW
Modules via the RTE. The RTE is an implementation of AUTOSAR’s middleware concept which is called VFB.
Within the AUTOSAR architecture as specified in release 2.0 the diagnosis functionality of an ECU is realized by two BSW
Modules and one SWC:
• Diagnostic Communication Manager (BSW)
The DCM handles the communication with external diagnosis tools. It implements the necessary timing management and
message segmentation as specified for the KWP2000 and UDS protocol. Some important diagnostic services (e.g. ReadDTCInformation) are directly handled by the DCM.
• Diagnostic Event Manager (BSW)
The DEM is responsible for managing error entries in the ECU. This includes storing them persistently.
• Central Diagnostic Software Component (SWC)
The Central Diagnostic SWC’s responsibility is to implement the processing of vehicle manufacturer specific diagnosis requests
and dispatch the requests to other SWCs.
4. Integration of BSW Modules
AUTOSAR BSW Modules were designed to run within the AUTOSAR architecture. They therefore depend on the availability
of services provided by other BSW Modules. The system surrounding the BSW Modules has to pretend to be an AUTOSAR
architecture by providing these services. The system has to emulate the required services of the missing BSW Modules. In
the approach presented in this paper emulators are implemented for the missing BSW Modules which provide exactly the
required services. This means that the emulators provide the specified interfaces and behavior of the required services to the
integrated BSW Modules. The services are implemented with the means of the underlying operating system. Figure 4 shows
the architecture of this approach.
44
FORUM
5. DCM Integration
For the integration of the DCM services provided by the ComManager, the BSW Scheduler and the PDU Router have to be
emulated. In this section the required services are described and a
rough idea is given how these could be emulated.
Within the AUTOSAR architecture the ComManager is responsible
for activating the communication BSW Modules. This is done as
soon as the lower communication infrastructure of the AUTOSAR
architecture is initialized. The DCM is a communication BSW Module and therefore expects to be initialized by the ComManager. The
ComManager Emulator has to be hooked up with the SystemCommunicationInit() callback function of the MOST Supervisor Layer II.
As soon as the emulator receives the callback from the MOST Supervisor Layer II it can initialize the DCM by calling it’s the expected
callback function as specified in the AUTOSAR specifications.
Figure 4 - Integration of AUTOSAR Diagnosis
The DCM expects its main function for processing diagnostic requests to be triggered periodically by the BSW Scheduler. The
BSW Scheduler Emulator has to implement the periodical triggering of the DCM’s main processing function with the means
of the underlying operating system. For an operating system which is compliant to the POSIX standard it could spawn a
thread which calls the DCM’s main processing function. After executing the main processing function the thread would wait
for a signal from a periodic timer which is armed by the BSW Scheduler Emulator.
The periodic triggering of the DCM is a problematic requirement. The main processing function has to be triggered with a
high frequency because besides processing the diagnostic request it also calculates the timeouts. Only by triggering the main
processing function very frequently the jitter for the timeout can be kept at a minimum. The high trigger frequency implies
an increase in the consumption of Central Processing Unit (CPU) time. This is especially undesirable as most of the time no
diagnostic request has to be processed anyway. Within a high-end infotainment ECU the wasted CPU time might even be
higher than in an AUTOSAR ECU as process switching might be necessary if multiple processes are executed in parallel.
Another feature of the DCM can be exploited to reduce the CPU time being wasted. The DCM is specified to inform the ComManager every time it has received a diagnostic request or it has ended processing a diagnostic request. The ComManager
Emulator can be implemented to forward these callbacks from the DCM to the BSW Scheduler Emulator. The BSW Scheduler
Emulator can then arm and disarm the timer based on these callbacks. By this implementation the periodical triggering of the
DCM main processing function is reduced to the period of time needed for actually processing diagnostic requests.
The PDU Router provides an interface for receiving and sending messages on an abstract level. The DCM uses this interface for
receiving and sending its diagnostic messages. The main responsibility of the PDU Router within the AUTOSAR architecture
is to dispatch incoming and outgoing messages to the BSW Modules which are in charge for processing them. Within the
MOST Netservices for incoming messages the Command Interpreter takes care of that. An implementation of the PDU Router
Emulator can exploit this by providing a diagnosis FBlock. The Command Interpreter simply is configured to forward incoming
diagnostic requests to that diagnosis FBlock. For outgoing messages the emulator will use the Application Message Service
(AMS) provided by the Netservices Layer I.
In both cases – incoming and outgoing messages – the PDU Router Emulator acts as an adapter. It converts the MOST messages into the message format required by the DCM and vice versa.
As mentioned in the previous section the DCM does not forward all diagnosis requests to the Central Diagnosis SWC. Some
important diagnosis requests are being directly processed by the DCM. For those requests concerning the monitoring and
45
30TH SEPTEMBER 2008
STUTTGART - GERMANY
management of the ECU’s error entries the DCM communicates with the DEM. The DEM does not have to be emulated as
it also is being integrated.
6. DEM Integration
The DEM itself depends on the services of the ECU State Manager and the NVRAM Manager. In this section the required
services of these two BSW Modules are described and a rough idea is given how these could be emulated.
The initialization of the DEM is not triggered by the ComManager as it does not depend on the communication infrastructure
to work correctly. It is initially triggered by the ECU State Manager.
The DEM expects to be initialized in a two-phased way. It provides two callback functions. The first callback function initializes
the DEM’s ability to accept error entries from other BSW Modules and from SWCs. At that time the DEM will not yet store the
error entries persistently. This functionality of the DEM is initialized by the second callback function. It is to be called as soon
as the persistent memory management (NVRAM Manager) is initialized.
When integrated into a high-end infotainment ECU the DEM is not part of the operating system. It is run as part of an application process.
At the point in time when the DEM is started the operating system including the file system is already up and running. A
two-phased initialization approach is therefore not necessary. The emulation of the ECU State Manager simply boils down to
calling the two callback functions immediately when the process running the DEM is started.
The DEM requires the services of the NVRAM Manager for writing/reading error descriptions to/from persistent memory. The
interface of the NVRAM Manager works with block identifiers to determine where to write/read data to/from the persistent
memory. The NVRAM Manager Emulator needs to map the block based interface to a file system. A pragmatic mapping
approach is to simply create a file for each block.
7. Central Diagnostic SWC Integration
Besides the listed BSW Modules the DCM also depends on the presence of the Central Diagnostic SWC. As mentioned before diagnostic requests specific to a vehicle manufacturer are not handled by the DCM. They are delegated to the Central
Diagnostic SWC.
The AUTOSAR architecture defines that SWCs and BSW Modules do not communicate directly with each other. They exchange data via the RTE. To enable the communication between the DCM and the Central Diagnostic SWC the integration
of the RTE into the high-end infotainment ECU is required.
The RTE depends on the services of the AUTOSAR OS. Hence an emulation of the AUTOSAR OS is required. This means that
calls to AUTOSAR OS services from the RTE have to be mapped to the appropriate OS services of the underlying operating
system. For a POSIX compliant operating system this means mapping the AUTOSAR OS services to threads, timers, mutexes
and conditions.
The integration of the RTE not only allows the communication between the DCM and the Central Diagnostic SWC but also
enables a further use case. As SWCs only depend on the RTE the presence of an RTE enables the deployment of SWCs in general. Unfortunately AUTOSAR does not provide a stack for MOST. This implies that the deployed SWCs can not communicate
with SWCs on other ECUs (remote communication).
By providing an additional module which will be called a MOST Proxy the previous described limitation can be dropped. The
MOST Proxy proxies the interfaces of all the external SWCs with which the deployed SWCs communicate. Instead of communicating with their actual communication partners, located outside the ECU, the SWCs communicate with the MOST Proxy
(see Figure 5). This way the RTE only has to handle communication between locally present components. From the RTE’s
point of view no MOST access is required. The MOST proxy takes care of converting the AUTOSAR VFB calls (Sender/Receiver,
Client/Server) to MOST Function Block calls (Set, Get, Status, …) and vice versa.
46
FORUM
With the MOST Proxy in place AUTOSAR SWCs deployed on the
MOST ECU are able to communicate over the MOST ring with any
other SWC or FBlock.
8. Conclusion
Developers of MOST ECUs can benefit from reusing selected existing implementations of AUTOSAR BSW Modules and SWCs. As
exemplarily shown for AUTOSAR’s diagnosis functionality AUTOSAR
BSW Modules and SWCs can be ported and executed on a high-end
infotainment ECU. This is achieved by partially emulating the AUTOSAR architecture.
Still the described integration of the AUTOSAR modules is rather
Figure 5 – Communication via MOST Proxy
loose. A stronger coupling between the MOST stack and the ported
AUTOSAR diagnostic modules would be desirable. Errors occurring within the MOST stack could also be passed to the DEM.
This would make them accessible to external diagnostic tools in the same way as the other errors.
9. References
[1] AUTOSAR development partnership: "AUTOSAR: Technical Overview”,
http://www.autosar.org/download/r2/AUTOSAR_TechnicalOverview.pdf, 2006
[2] AUTOSAR development partnership: "AUTOSAR: Specification of Diagnostic Communication Manager”,
http://www.autosar.org/download/r2/AUTOSAR_SWS_DCM.pdf, 2006
[3] AUTOSAR development partnership: "AUTOSAR: Specification of Diagnostic Event Manager”,
http://www.autosar.org/download/r2/AUTOSAR_SWS_DEM.pdf, 2006
[4] AUTOSAR development partnership: "AUTOSAR: Specification of Communication Manager”,
http://www.autosar.org/download/r2/AUTOSAR_SWS_ComManager.pdf, 2006
[5] AUTOSAR development partnership: "AUTOSAR: Specification of PDU Router”,
http://www.autosar.org/download/r2/AUTOSAR_SWS_PDU_Router.pdf, 2006
[6] AUTOSAR development partnership: "AUTOSAR: Specification of ECU State Manager”,
http://www.autosar.org/download/r2/AUTOSAR_SWS_ECU_StateManager.pdf, 2006
[7] AUTOSAR development partnership: "AUTOSAR: Specification of BSW Scheduler”,
http://www.autosar.org/download/r2/AUTOSAR_SWS_BSW_Scheduler.pdf, 2006
[8] AUTOSAR development partnership: "AUTOSAR: Specification of Operating System”,
http://www.autosar.org/download/r2/AUTOSAR_SWS_OS.pdf, 2006
[9] AUTOSAR development partnership: "AUTOSAR: Specification of RTE Software”,
http://www.autosar.org/download/r2/AUTOSAR_SWS_RTE.pdf, 2006
Electronic Control Unit
Basic Software
Software Component
Diagnosis Communication Manager
Diagnosis Error Manager
Application Message Service
Central Processing Unit
Function Block
CONTACT
ECU:
BSW:
SWC:
DCM:
DEM:
AMS:
CPU:
FBlock:
CONTACT
10. Glossary
Paul Hoser
BMW Car IT GmbH
Petuelring 116
80809 Munich
Germany
47
30TH SEPTEMBER 2008
STUTTGART - GERMANY
MO S T PH Y SI C A L L AYER
Plastic Optical Fiber Coupling
Systems: A Novel Optomechanical Modeling Approach
Els Moens, Vrije Universiteit Brussel
Michael Vervaeke, Vrije Universiteit Brussel
Youri Meuret, Vrije Universiteit Brussel
Heidi Ottevaere, Vrije Universiteit Brussel
Carl Van Buggenhout, Melexis Ieper NV
Piet De Pauw, Melexis Ieper NV
Hugo Thienpont, Vrije Universiteit Brussel
1. Introduction
Plastic optical fiber (POF) is nowadays used in lots of applications like data communication systems and the automotive due
to its advantages: lightweight, robust, immune to electromagnetic interference, cheap and easy to install (Ref. 1).
The system that is discussed in this work ensures the efficient coupling of light from a source (resonant cavity light emitting
diode–RCLED) into a plastic optical fibre. The specification that has to be met is the minimum guaranteed power coupled into
the POF. The system also has to be low cost and mass manufacturable since economic factors are as crucial for the choice of
the optimal system.
In order to design a realistic system we need to know its mechanical parameters and the optical parameters of the used light
source. We first measured the optical properties (optical spectrum, far field pattern and total output power) of the source
at different temperatures and drive currents. Using this data we designed the coupling module and performed a tolerance
analysis of the total system.
2. Description of the Problem/Challenge
The realistic modeling of the coupling system, needs a realistic source model. Therefore we fully characterized the RCLEDs
chosen for the system design. Measuring of the optical properties of a source is straightforward if the light is emitting in air.
However for many interesting coupling configurations the light will be emitted in a transparent material like epoxy. Therefore
we developed a measurement method to characterize the source while emitting light in a transparent material. A second
challenge was to design a coupling unit with a high efficiency but with low fabrication cost. In this work we will propose five
different designs and compare their efficiency and tolerance to mechanical misalignments.
3. Introduction to Solutions and Results
3.1. Measurements
As already mentioned in the introduction we performed three types of measurements on the RCLEDs (Ref. 2). All of them
were performed at different temperatures and drive currents since the final optical system should meet the specifications for
extreme temperature conditions.
We examined for five RCLEDs the shift of the peak wavelength due to variations in temperature (-40°C to 115°C) and drive
current (7.5mA to 20mA) while keeping drive current constant. The measurements show us that increasing temperature
shifts the peak wavelength to larger values as do higher drive currents. The average wavelength shift due to changes in
drive current at room temperature is (0.054±0.043)nm/mA (tolerance taken at ). At 115°C this shift is somewhat smaller:
48
FORUM
(0.034±0.005)nm/mA. Varying the temperature at a drive current of 15mA results in an increase of (0.137±0.020)nm/°C,
which is in good correspondence with the literature (0.11nm/°C, Ref. 3).
The second important source characteristic is the far field pattern of the emitted light. Varying the drive current from 7.5mA
to 20mA, while keeping the RCLED at room temperature, has almost no influence on the far field pattern. On the other hand,
keeping the drive current constant at 15mA and changing temperature from -20°C tot 115°C causes significant changes in
the shape of the angular distribution. We calculated at each measured angle the maximum procentual difference between
the measured far-field patterns and calculated the average over all angles. At 115°C the far-field pattern is on average 18.7%
smaller than at room temperature, while at -20°C it is 11.3% broader (Fig. 1).
Figure 1: The far field pattern of the RCLEDs for different drive currents at room temperature (top) and for different temperatures at 15 mA (bottom)
The final parameter measured is the total output power. At room temperature there is a change of (0.063±0.051)mW/mA
in total output power (tolerance taken at ), at 60°C and 115°C this change is respectively (0.627±0.074)mW/mA and
(0.045±0.013)mW/mA. Keeping the drive current constant and increasing temperature from -40°C to 115°C, increases the
total output power until room temperature is reached and decreases output power at temperatures higher than room temperature. At -40°C the average total output power is (0.481±0.197)mW, at room temperature it is (3.192±0.662)mW and at
115°C it lowers to (0.373±0.121)mW.
To measure the source properties in epoxy we glued a half ball lens in BK7, with radius large compared to the emitting
aperture of the RCLED, on top of the source such that the emitting surface of the RCLED was exactly at the center of the
spherical lens. This ensures all light emitted by the source to be perpendicular incident on the surface of the lens, so that the
direction of the light is not altered due to refraction. Therefore the far-field pattern of the RCLED with the lens glued on top
that is measured is the same as the one emitted by the source in epoxy. The far field pattern is on average (36.1±28.1)%
smaller when emitting in epoxy instead of in air (Fig. 2) and there is an increase of the output power of (19.9±11.6)%. Both
measurements were performed at room temperature and 15mA.
49
30TH SEPTEMBER 2008
STUTTGART - GERMANY
Figure 2: Measurement of the far field pattern in air and in epoxy
3.2. Design
To design the system we used ASAP 2008 (Ref. 4). The POF we used has a core with a diameter of 980μm and a refractive
index of 1.41. The diameter of the cladding is 1000μm and its refractive index is 1.49. To model the numerical aperture (0.48)
of the POF and the Fresnel losses at the POF entrance in a realistic way, the detector is positioned inside the core at a large
distance from the fiber input facet. Due to mechanical constraints, the input facet has to be at a distance of 443μm from the
source. Attenuation of the light is not taken into account. The RCLED is modeled as an emitting surface of 83μm and light is
emitted uniformly from this aperture. Dispersion phenomena are not taken into account in our simulation model.
From the experimental characterization of the sources, we have seen that emission in a higher index material increases the
total output power and changes the angular distribution of the outgoing light. We assume an index of refraction of 1.5 for
the immersion material. Since temperature also influences the properties of the light source, we investigated the coupling
efficiencies both at 60°C and 105°C.
Different possible configurations (Fig. 3) for the coupling unit are investigated (Ref.2). In the glob top configuration, an epoxy
drop is put over the emitting surface of the RCLED and the RCLED cavity is filled with silicone. Alternatively the cavity could
first be filled with silicone. An epoxy drop is subsequently deposited on the silicone. Another possible configuration is the
ball lens configuration, where a small glass ball is positioned on-axis at a certain distance from the RCLED aperture, using a
small pedestal. The third configuration differs from the second one in the fact that the ball lens is immersed completely in
the layer of epoxy. We also allow the variation of the refractive index of the ball lens material. We call it the buried ball lens
configuration. For the CPC configuration we place a compound parabolic concentrator (Ref. 5) around the RCLED. The last
configuration, the lens configuration, uses a mini-lens positioned in the RCLED cavity. For each of these configurations, the
coupling efficiency was simulated in ASAP (Tab. 1). Both the relative coupling efficiency and absolute total output power into
the POF are tabulated. We calculated the coupled power taken into account that the emitted power in air of the RCLED is
1.18mW (60°C) and 0.86mW (60°C) at 23.75mA drive current. When emitting in an immersion material, the power is taken
to be 1.36mW (60 °C) and 0.95mW (60°C) .
Figure 3: Five different configurations for the collection of the light emitted by the RCLED to the PO
50
FORUM
Coupling efficiency (%)
Coupled power (dBm)
60 °C
105 °C
60 °C
105 °C
Glop Top
71
69
-0.15
-1.83
Ball lens
79
78
-0.30
-1.73
Buried ball lens
77
76
0.20
-1.41
CPC configuration
82
82
-0.14
-1.52
Lens configuration
80
78
-0.25
-1.73
Table 1: Coupling efficiency and coupled power at different temperatures for the five configurations
We conclude that the coupling efficiencies are not affected significantly by temperature. Furthermore, the optimal design
parameters for the highest coupling efficiency are nearly the same in both cases (Ref. 2). The specification of a minimum
coupled power of -3.5dBm is also met for every configuration and temperature.
3.3. Tolerancing
In reality the fabricated system never attains the ideal design. We will use a Monte-Carlo based optimization algorithm to
define the optimal tolerances to guarantee a minimum coupled power into the system. The full 3D opto-mechanical system
together with the behavior of the RCLED source in the complete temperature range is introduced in this system.
The system to be optimized consists of a package part containing the RCLED and the optical coupling components, and a
ferrule part with the POF. Simulations were carried out using a coupled framework between Matlab (Ref. 6) for the mechanical description and Zemax (Ref. 7) for the optical properties. The parameter we want to optimize is the total process yield,
which is the number of systems that will comply with a given specification list with respect to the total number of systems,
by setting the nominal values and the probability density functions of the parameters (Ref. 2).
The tolerancing was performed for the glob top and ball lens configuration. The choice for these configurations was based
on initial manufacturability and cost predictions. For each of the configurations the correct source model and source output
power were implemented for a given temperature. The aim for both configurations is to achieve a minimum coupled output
power of -3.5dBm over the complete temperature operating range. The results of the optimization of both systems can be
found in Tab. 2.
Parameter
Ball lens
Glop top
ZC
145±4.4μm
179±14.4μm
R
138±5.1μm
167±8.8μm
ZL
54±19.6μm
174±18.9μm
Table 2: Ball lens and glob top tolerancing. Tolerance bands are taken at 3x
We found that the coupled power violation probability remains well below 10-6 when including fabrication and assembly
tolerances of a suitable ball lens. From the results we already see a challenge for the glob top fabrication: the ideal system
is a half-sphere on a pedestal of on average 5μm since the average of ZC is larger than ZL. The glob top configuration has
a slightly larger positioning and radius of curvature than the ball lens system. Both configurations will ensure the minimum
specified coupling power from the tolerancing point of view.
51
30TH SEPTEMBER 2008
STUTTGART - GERMANY
4. Conclusions
We measured the optical spectrum, far-field pattern and total output power of the RCLED source at different temperatures
and drive currents to achieve a realistic simulation model. This model was used to investigate the coupling efficiency of different coupling configurations. We found that increasing temperature only decreases the coupling efficiency with a couple
percents. Comparing the proposed designs shows that all configurations have coupling efficiencies in the same range. A last
step in this case study was to perform a tolerance analysis study on two of these coupling systems: the ball lens and glob top
configuration. We found that the glob top configuration is requiring easier tolerances than the ball lens system. The probability to obtain a system violating the minimum -3.5dBm coupled optical power specification is in both cases lower than 10-6.
Acknowledgements
The DWTC-IAP, FWO, GOA, 6th FP European Network on Micro-Optics (NEMO) and the OZR of the Vrije Universiteit Brussel
supported this work. The FWO, which provided H. Ottevaere a “Postdoctoraal Onderzoeker” fellowship, supported her
work.
References
52
Els Moens
Michael Vervaeke
Youri Meuret
Heidi Ottevaere
Hugo Thienpont
Dept. Of Applied Physics and Photonics
Pleinlaan 2
1050 Brussel
Belgium
CONTACT
[1] O. Ziemann, J. Krauser , P. E. Zamzov, W. Daum; POF Handbook:
Optical Short Range Transmission Systems; Springer, 2nd edition
2008.
[2] E. Moens, M. Vervaeke, Y. Meuret, H. Ottevaere, C. Van Buggenhout, P. De Pauw, H. Thienpont; Realistic opto-mechanical modelling of plastic optical fiber coupling systems, Proc. SPIE 6992, n.
699232, 2008.
[3] P. Sipilä, M. Saarinen, M. Guina, V. Vilokkinen, M. Toivoren, M.
Pessa; Temperature behavior of resonant cavity light-emitting diodes at 650 nm; Semicond. Sci. Technol. 15 (2000), 418-421.
[4] Advanced Systems Analysis Program (ASAP) is a trademark of
Breault Research Organization, Inc., 6400 East Grand Road, Suite
350, Tucson, AE 85715; www.breault.com
[5] R. Winston, J. C. Minano, P. Benitez, Nonimaging optics, Elsevier
Academic Press, 2005.
[6] http://www.mathworks.com.
[7] http://www.zemax.com.
Carl Van Buggenhout
Piet De Pauw
Melexis Ieper NV
Rozendaalstraat 12
8000 Ieper
Belgium
FORUM
MO S T PH Y SI C A L L AYER
nanoStructures™ Technology and
Possibilities for the Next Generation
of Optical Fibers for Vehicular
Applications
Claudio Mazzali, Corning Incorporated
Paulo Dainese, Corning Incorporated
Mike Pambianchi, Corning Incorporated
Manish Sharma, Corning Incorporated (w/o image)
Guenther Uhlenhuth, Corning Incorporated
Introduction
The optical communications industry began in the 1970’s when glass optical fibers with attenuation lower than 20 dB/km
were demonstrated. Then in the 1990’s chromatic and polarization mode dispersion became the main challenges as long haul
fiber networks were built. Other challenges came with glass optical fiber penetrating the metro and access environments.
With the arrival of fiber-to-the-home (FTTH), optical fibers are now the end-to-end transmission medium connecting individual residences via transoceanic links, and are starting to penetrate even inside buildings and homes. This continual expansion
of optical fiber is a testament to the fundamental versatility of glass optical fiber in evolving new attributes to suit changing
deployment environments.
The new frontiers for glass optical fiber lie in applications such as automotive and in-home networks, where distances are
shorter and network costs are supported by fewer users. Here simplicity, robustness, and installation cost drive the economics of deployment much more than transmission performance. The fiber-to-the-home environment has already created
some of the innovations in glass optical fiber needed to address these networks. We present an overview of these innovations, and describe the recent technologies with potential to address future needs in these networks.
Innovations Driven by Fiber-to-the-Home
Fiber-to-the Home is the most stringent environment where glass fibers are used today. The ability to handle optical cable
using procedures no more complex than those for copper cable is critical in justifying the economics of FTTH deployments.
This means not only that the fiber optic cable itself should be robust enough to support tortures during cable routing throughout small spaces encountered inside buildings, but also that bends, kinks, tension, termination and even the use of staples
should not create limitations that can consequently increase deployment cost. It is known that for multiple dwelling units
(MDUs) and in-home wiring applications, bend radii in the range of 5 mm are very common and bending losses must be kept
to minimum. Bending losses of less than 0.1 dB/turn are critical to ensure the network performance under practical conditions[1] such as tight 90° corners, corners under load, multiple staples and excess cable storage in small spaces.
A combination of multiple innovations on fiber, cable and termination solutions were recently developed to enable these
installation challenges. One of the key breakthroughs was the development of the nanoStructures™ technology [2-3], which
allowed single-mode glass fiber design to achieve extremely low bending loss.
53
30TH SEPTEMBER 2008
STUTTGART - GERMANY
nanoStructuresTM Technology
There are several approaches to achieving improved bend performance in glass optical fibers; however, many of these
solutions are either not bend insensitive enough for the applications of interest here, too complex for mass production, or
incompatible with simple, low cost installation procedures. The recently developed nanoStructuresTM technology for manufacturing optical fibers is a breakthrough that adds new dimensions to the conventional fiber design space. It enables new fibers with superior bend performance that are backward-compatible
with legacy fiber plant and existing field installation equipment and
procedures, while remaining simple enough for large scale manufacturing
Fig. 1 shows a schematic of the fiber design, which consists of a
germania-doped core and a nano-engineered ring in the cladding.
The ring consists of nanometer-sized airlines along the fiber that are
incorporated in the glass during the fiber processing. These airlines
can have diameters of several hundred nanometers, with the air fill
fraction designed to be between 1 to 10 percent. The size characteristics of airlines and air fill fraction significantly affect the optical
properties of the nano-engineered region, thereby influencing the
fiber performance.
Fig. 1
Fig. 1. Diagram of fiber with nanoStructuresTM ring.
The nano-engineered ring design offers advantages compared to other technologies. Fundamentally, the refractive index
dependence of glass having nanometer sized features is very different from that of glass with conventional dopants used in
fiber manufacturing. The effective index is mostly determined by the air hole size and the air fill fraction. This behavior enables the engineering of this “virtual dopant” to achieve different attributes, tailoring the waveguide properties for different
applications.
Fig. 2a. Example of relative index change as a
function of wavelength. Fig. 2b. Comparison
of bending performance of nano-engineered
fibers with standard single-mode fiber and
trench fibers.
Bending losses of the nano-engineered fibers
were measured using mandrels with different
Fig. 2a.
Fig. 2b.
radii. Fig. 2b compares typical bend losses as
a function of bend radius for the fiber with nanometer sized features, standard single-mode fiber and trench fiber at 1550 nm. This figure shows that the nano-engineered
fiber has about 500 times lower bending loss than the standard single-mode fiber, and 6-10 times lower than trench fibers.
The bending loss at 5 mm radius is 0.03 dB/turn.
This example was designed for a specific FTTH application and so had other design boundaries to make it compatible with
existing telecom standards. The lowest bend loss reported on figure 2b was achieved with a nanoStructures-based fiber
which was not necessarily compliant with the regular ITU standard for telecom applications; this gives some idea of what
nanoStructures technology is capable of for other applications outside telecommunications.
54
FORUM
When combined with rugged cable designs, this technology enables fiber optic cable to be routed with installation procedures similar to those commonly used with copper cables. Figure 3 illustrates some of the “tortures” that an optical cable
can be subjected to in in-building installations. Figure 4 shows typical loss experienced by glass fibers with nanostructures
technology under different deployment test conditions.
Figure 3: Examples of some of the “tortures” an optical cable can be subjected to in in-building installations. a,b) Routing
through stud holes, c) Sharp 90 degree under tension, d) Stapling optical cable directly to wood and e) Multiple wraps on
very small bend radius.
Figure 4: torture test with several events that cause a tight bend into
an optical cable such as staples, corners under load, and staples; The
chart shows the cumulative optical loss measured at 1550 nm for a
rugged cable with nanoStructures-based bend-insensitive fiber;
Termination is another key process step in the installation of simple media oriented networks in the spaces under discussion. Typical
glass fiber termination methods employed in telecommunications
are too complex and time consuming for deployment within buildings and automobiles. This is not caused by technology limitation, and developing solutions that trade precision for low cost and
simplicity is possible. Some in-field connectorization methods have
Fig. 4
been created to simplify fiber handling either based on “crimp and
cleave” techniques or mechanical splicing using simple handheld tools such as the ones shown in Fig. 5. This specific solution
is capable of installing an in-field connector in a single-mode fiber in less than 2 minutes, with minimum training required,
and achieves typical connector losses in 0.1-0.2 dB range. If connector losses of 2 – 2.5 dB are acceptable this installation
procedure can be greatly simplified and shortened.
Figure 5: Portable in-field termination machine designed to connectorize single-mode fiber with loss <0.2 dB. This evolution
shows the potential of much simpler termination for GOF when loss spec is relaxed to <2 dB
55
30TH SEPTEMBER 2008
STUTTGART - GERMANY
Upcoming Developments and Applications
While MOST has been developed primarily for the automotive environment, it is reasonable to consider its application to
other networks where synchronous networking of multiple digital audio and video streams is valuable. Examples of such
networks include public address systems in airports, stadiums, etc.[4], and security systems in buildings, in which multiple
video displays, digital video cameras, and audio loudspeakers are networked together in applications requiring real time/low
latency. In-home networking is also moving toward configurations where an hybrid optical/wireless network defines the best
combination of capacity, mobility and flexibility. Low cost and ease of installation are key requirements for the economic case
of these systems, creating a direct connection with the trend initiated by FTTH deployments.
Due to its intrinsic properties glass optical fiber presents natural advantages as a transmission medium for these networks,
which often span links longer than 100m. For glass fiber to be used in these systems, it needs to be compatible with the cost
and the installation environment of these networks. The requirement for low total system cost generally means operating
with LED-based fiber-optic transceivers (FOTs) operating at 650 nm. It also implies the use of low cost optical connectors
made by very simple injection molding or similar technology. Low connection loss is not a strong requirement in these cases
and needs to be traded off against low cost connectorization. The combination of recently developed technologies for glass
fiber manufacturing, with larger core diameter and high numerical aperture are the natural path to capture light efficiently
from LED sources and accommodate the loose alignment tolerances within connectors. This will provide MOST networks
access to the inherent performance advantages of glass while maintaining the simplicity and low cost that has enabled MOST
to be successful in automotive networks.
[1] D. Z. Chen, W.R. Belben, J.B. Gallup, C. Mazzali, P. Dainese, and
T. Rhyne, “Requirements for bend insensitive fibers for Verizon’s
FiOS and FTTH applications”, (OFC/NFOEC) 2008, San Diego, CA,
Feb. 24-28, 2008.
[2] M.-J. Li, Member, OSA, Member, IEEE, P. Tandon, D. C. Bookbinder, S. R. Bickham, M. A. McDermott, R. B. Desorcie, D. A. Nolan, J.
J Johnson, K. A. Lewis, and J. J. Englebert, “Ultra-low Bending Loss
Single-Mode Fiber for FTTH” (OFC/NFOEC) 2008, San Diego, CA,
Feb. 24-28, 2008 – PDP10
[3] P. Dainese, M. Edwards, T. Rhyne, and D. Chen, “Fiber innovation optimizes FTTH reach, reduces installation cost”, March 2008
issue of Lightwave Magazine, volume 25
[4] For example, Bosch Praesidio Public Address System, http://www.
bosch-sicherheitsprodukte.de/content/language2/html/1611_
ENU_XHTML.as
56
CONTACT
REFERENCES
Claudio Mazzali
Paulo Dainese
Mike Pambianchi
Manish Sharma
Guenther Uhlenhuth
One Riverfront Plaza
14832 – Corning, NY
United States
T +1 607 974 4000
E mazzalic@corning.com
FORUM
MO S T C OM PL I A N C E AND QUALITY
Automotive Application Recommendation
for MOST150 Physical Layer Components
Joerg Angstenberger, RELNETyX AG
Dr. Viktor Tiederle, RELNETyX AG
Introduction:
The new developed Physical Layer for MOST150 will come up not only by increasing the bandwidth of MOST up to 150Mbps but
with a newly developed packaging concept for the Fiber Optical Transceiver (FOT) called HEAVEN. The HEAVEN concept will be an
additional packaging option to the existing SIDELOOKER design.
For the development of a MOST Physical Layer device in general, 2 standards are relevant and of concern:
1. Functional Specification:
“MOST Physical Layer Specification” that describes the functional behaviour of the device.
2. Qualification Standard:
“Automotive Application Recommendation for optical MOST Components for MOST (AAR)” The AAR was released to describe how
to qualify MOST25 devices in SIDELOOKER packages according to international automotive semiconductor and fiber optics standards
to fulfil quality and reliability requirements.
With the introduction of the MOST150 Physical Layer Specification and the fact that there will be 2 different package concepts
coexisting (SIDELOOKER and HEAVEN), there is a need to establish qualification procedures to cover both variants independent from
the speedgrade.
Description of challenge
The qualification procedure of a MOST device in the existing SIDELOOKER design is based on
2 consecutive qualification procedures:
SIDELOOKER Qualification Procedure
1. Fiber-optical Transceiver (FOT) is qualified according to Automotive Application Recommendation for optical MOST Components
section FOT by the manufacturer
of the FOT.
2. Assembled PIGTAIL (Connector, PIGTAIL-Fiber/Lens and integrated qualified FOT) is qualified according to Automotive Application
Recommendation for optical MOST Components section PIGTAIL by the manufacturer of the pigtail.
The HEAVEN package concept enables the assembly of FOT, connector and pigtail-fiber on ECU (Electronic Control Unit) level.
However, this means the assembly and overall function of the final MOST component is not covered by the qualification process of
these subcomponents. Therefore the qualification procedures of the subcomponents have to consider additional tests due to the
aspect of interchangeability and overall function of the final MOST component. This will guaranty quality and reliability even after
the assembly.
57
30TH SEPTEMBER 2008
STUTTGART - GERMANY
HEAVEN Qualification Procedure
1. Separate qualification of HEAVEN Fiber-optical Transceiver (FOT) by the manufacturer of the FOT.
2. Separate qualification of HEAVEN pigtail-fiber by the manufacturer of the pigtail-fiber.
3. Separate qualification of HEAVEN connector by the manufacturer of the connector part.
Solution
The existing Automotive Application Recommendation for MOST 2V1 was developed especially for MOST25 devices in SIDELOOKER
package.
The fact that the process of the assembly will be completely different for HEAVEN and SIDELOOKER requires the definition of a
separate qualification procedure for each package design. For the SIDELOOKER variant it is possible to adapt the existing AAR 2V1.
All relevant qualification parameters of the FOT package are addressed in section FOT (Semiconductor, Figure 1) and all relevant qualification parameters of the pigtail construction (mechanical and optical parameters that are influenced by the pigtail design, Figure
2) are described in section PIGTAIL. The characterisation procedure is due to the corresponding MOST Physical Layer Specification.
Only speedgrade related definitions have to be adjusted and minor changes of the package (e.g. Number of leads) need to be taken
in account.
SIDELOOKER - FOT
Figure 1: Hamamatsu FOT Tx (MOST25/150)
Qualification Scope:
-
semiconductor related parameters
package related parameters
optical Interface
characterization of electrical and optical parameters
Figure 1
Dimension & Samples: Physical Dimensions (PD), Reference Parts (REF)
Functional: ESD (ESD) and EMC (EMC) tests as well as semiconductor
related test like Gate Leakage (GL) and Latch Up (LU)
Climatic: Chemical Resistance (CR)
Manufacturing: Moister Level Definition (MLD), Solderability (SD), Resistance to Soldering Heat (RSH), Bond Pull Strength (BP) and
Bond Shear Strength (BS).
Mechanical: Lead Pull (LP), Lead Bend (LB) and Lead Torsion (LT) tests
Operating Life: High and Low Temperature Operating Life tests (HTOL, LTOL), Temperature Cycling (TC) or Temperature Shock (TS) with Preconditioning (PRE), Temperature
and Humidty Biased (THB) with Preconditioning (PRE) and resistance for Corrosive Atmosphere (CA)
Characterisation: Functional Characterisation (CHA) of all relevant parameters of the
FOT according to corresponding MOST Physical Layer specification
SIDELOOKER - PIGTAIL (int. FOT)
Figure 2: Tyco Micropigtail (here for MOST25)
58
Figure 2
FORUM
-
mechanical construction
mechanical interface
optical interface
characterization of optical and mechanical parameters
Functional: ESD (ESD) and EMC (EMC) Tests
Climatic: Chemical Resistance (CR), Thermal Pistoning (TP)of fiber
Climatic and Mechanical: Stepped Temperature Test (STT), Mechanical Shock (MS), Vibration Random (VR) and Vibration Sinus (VS)
Manufacturing: Plugging Frequency (PFR), Angular Plugging (AP), Solderability (SD), Resistance to Soldering Heat (RSH)
Mechanical: Contact Torsion (CT), Wire Pulling (WP), Draw-Out Strength (DOS), Dust (D), Permanent Pulling (PP), Drop Test (DT),
Draw-Out Strength Connector (DSC)
Operating Life: High Temperature Operating Life Test (HTOL), Temperature Cycling or Shock (TC/TS), Temperature and Humidity Biased (THB), Temperature Humidity Cycling (HTC) and Corrosive Atmosphere (CA)
Characterisation: Functional Characterisation (CHA)of all relevant parameters of the PIGTAIL construction according to the corresponding MOST Physical Layer specification
For the HEAVEN variant it is necessary to define single qualification procedures due to the different single subcomponents. Section
FOT covers semiconductor related as well as mechanical and interface related tests (Figure 3). Section PIGTAIL-Fiber (Figure 4) covers
tests, that are related to the optical (e.g. fiber surface) and mechanical interface (e.g. attachment of ferrule to fiber, physical dimensions). Finally Section CONNECTOR proves the mechanical interface of the connector as well as the attachment of the pigtail-fiber
to the connector (Figure 5).
Besides the specification of qualification loads, the HEAVEN concept requires a specific definition of how to characterize the optical
interface of the FOT (different to MOST Physical Layer specification points SP2 and SP3!). Further a procedure is needed to characterize the attenuation of the pigtail-fiber. Only if both characterisations procedures (HEAVEN FOT and pigtail-fiber) are defined and
performed in accordance to each other, the overall function of a HEAVEN FOT from a certain manufacturer combined with specific
pigtail-fiber will comply to the MOST Specification.
HEAVEN - FOT
Figure 3: Hamamatsu FOT HEAVEN (MOST150)
-
semiconductor related parameters
mechanical construction
mechanical interface
optical Interface
characterization of electrical and optical and mechanical parameters
Figure 3
Overview Qualification Loads*
59
30TH SEPTEMBER 2008
STUTTGART - GERMANY
Functional: ESD (ESD) and EMC (EMC) tests as well as semiconductor
related test like Gate Leakage (GL) and Latch Up (LU)
Climatic: Chemical Resistance (CR)
Manufacturing: Moister Level Definition (MLD), Solderability (SD), Resistance to Soldering Heat (RSH), Bond Pull Strength (BP) and
Bond Shear Strength (BS).
Mechanical: Mechanical Shock (MS), Vibration Random (VR), Vibration Sinus (VS), Wire Pulling (WP) and Draw-Out Strength (DOS)
to verify the lock/spring mechanism. Drop Test (DT)
Operating Life: High and Low Temperature Operating Life Test (HTOL, LTOL), Temperature Cycling (TC) or Temperature Shock (TS)
with Preconditioning (PRE), Temperature and Humidity Biased (THB) with Preconditioning (PRE), Temperature Humidity Cycling (HTC),
Stepped Temperature Test (STT) and Corrosive Atmosphere (CA)
Characterisation: Functional characterisation (CHA) of all relevant parameters of the FOT according to the corresponding MOST
Physical Layer specification
*NOTE: The qualification loads are preliminary and still under discussion
HEAVEN – PIGTAIL Fiber
Figure 4: Pigtail Fiber HEAVEN (Prototype H/B)
- mechanical interface, physical dimensions
- optical Interface/surface
- attachment of ferrule to fiber
Fiber has to be qualified according to LV131 “Fiber optics in motor vehicles;
test guideline for LWL bulk stock”
Figure 4
Climatic: Chemical Resistance (CR), Thermal Pistoning of fiber (TP)
Mechanical: Wire Pulling (WP), Draw-Out Strength Ferrule (DOSF) to prove the mechanical attachment of the ferrule to the fiber.
Operating Life: Temperature Shock (TS), Temperature and Humidity Biased (THB) to prove the mechanical contact of the ferrule to
the fiber. Corrosive Atmosphere (CA) to test the influence on the fiber surface.
Characterisation: Functional characterisation (CHA) of all relevant parameters of the Fiber according to the corresponding MOST
Physical Layer specification.
60
FORUM
HEAVEN - Connector
Figure 5: Tyco Connector (similar to MOST25)
-
mechanical interface, physical dimensions
attachment of female connector housing to connector
Connector has to be qualified according to LV214 “Plug connectors in motor vehicles;
test guideline”
Figure 5
Mechanical: Dust (D), Drop test (DT), Wire Pulling Housing (WPH), Draw-Out Strength Ferrule Housing (DSFH), Mechanical Shock
(MS), Vibration Random (VR) and Vibration Sinus (VS) to prove the mechanical attachment of the ferrule housing to the connector.
Operating Life: Temperature Cycling (TC) or Temperature Shock (TS) to prove the mechanical attachment of the ferrule housing to
the connector.
Characterisation: Functional Characterisation (CHA) of all relevant parameters of the connector according to the corresponding
MOST Physical Layer specification.
Conclusion
CONTACT
To provide a speedgrade-independent qualification procedure for the SIDELOOKER design that covers as well the MOST25 as the
MOST150 devices, the plan is to release an update of the Automotive Application Recommendation for MOST devices - scope
SIDELOOKER in October 2008. The HEAVEN design will be covered by an additional qualification procedure called Automotive Application Recommendation for MOST devices - scope HEAVEN. This document is planned to be released by the end of 2008. With the
release of both documents it will be assured, that the well established qualification procedure for MOST25, that significantly increased the confidence level of MOST devices in terms of quality and reliability in the past, will cover existing and future MOST package
designs, independent from the speedgrade of the device.
Joerg Angstenberger
Dr. Viktor Tiederle
RELNETyX AG
Meisenweg 33
70771 Leinfelden-Echterdingen
Germany
T +49 711 69 39 780
61
30TH SEPTEMBER 2008
STUTTGART - GERMANY
MO S T C OM PL I A N C E AND QUALITY
Wolfgang Malek, RUETZ SYSTEM SOUTIONS
Georg Janker, RUETZ SYSTEM SOLUTIONS (w/o image)
Introduction
Systems integration of infotainment systems continues to be a big challenge. The MOST standard has contributed, in no small
way, to highly structured design and development and implementation according to the principles of a distributed network.
Therefore, tools and processes for successful implementation are on a high level, today. Practical experience shows, however,
that there is room for improvement as far as coordination of validation by car manufacturers and suppliers is concerned.
In this paper, we shall present a critical evaluation of the current situation and show how issues can be resolved in a very
practical manner and integrated into the current systems integration landscape, even in the short-term.
Systems Integration - State-Of-The-Art Today
From A Supplier's Perspective
Nowadays, suppliers are more or less free to decide on implementation issues of required functionalities of control devices.
This is mainly due to the fact that rapid prototyping and automatic code generation can only be partially combined with
increasing complexity of multi-media control devices, and even then it is difficult to achieve. Detailed specifications which
display requirements of car manufacturers in a sufficiently detailed manner have only been available more recently and have
since been requested more often. A problem for suppliers is the absence of guidelines on how to provide evidence for implementation of the required scopes. This is not only true for applications but also for network functionality. It is often the
case that while a lot of effort is put into development and validation by suppliers results do not conform with requirements
by car manufacturers. Therefore subsequent improvements of essential functionalities are necessary, at a relatively late point
in time. These subsequent improvements block developments of higher layers which would have been envisaged for that
particular point in time.
Since suppliers are always at risk that their efforts are not recognized by car manufacturers and that they are faced with
unexpected requirements and acceptance criteria it is not surprising that suppliers tune down their initial efforts and instead
wait for the reaction of car manufacturers at the time of the first acceptance test in order to make improvements at that
point in time.
Due to an increased emphasis on cost reduction validation measures are being reduced during early phases and errors are
neither evaluated nor corrected until car manufacturers have detected these errors and requested remedy. If it is possible to
redefine any remedial measures as a change request this may be beneficial in terms of cost-efficient work within a supplier's
company but it is not consistent with high quality of a developed device and is therefore not in the interest of the end customer.
From A Car Manufacturer's Perspective
Currently, a car manufacturer cannot rely on the performance of a supplier without verification but has to make a significant
investment to ensure validation of control devices. Validation also affects areas which do not necessarily contain the special
scopes of car manufacturers but are contained within the network layer of MOST implementation. Reports by suppliers on
validation scopes that were performed provide an overview of work done but do not provide an instant indication of the
62
FORUM
quality of any supplied control device. This is why many essential test scopes are developed, performed and evaluated by car
manufacturers, tying up valuable time of MOST systems integration experts. Beginners' mistakes in control devices supplied
can lead to very late completion or non-completion of really important tasks of systems integration.
From A Test House Perspective
Currently, test houses support systems integration processes at the level of MOST compliance verification. Compliance verification constitutes an important part of ensuring network functionality and interoperability. However, it has only affected
a small part of systems integration tasks so far. In order to deliver quality in
terms of compliance verification and ISO 17025, test houses have gone to
great lengths to develop an infrastructure, which often goes beyond what car
manufacturers' and suppliers' test systems can deliver in terms of accuracy
and reproducibility. Currently, test houses are only rarely given tasks beyond
compliance processes. Test house expertise is often not taken seriously and
compliance is often regarded as an inconvenient and bothersome issue. The
reasons for this are often to be found in the costs involved and the mentality of
suppliers to keep their cards close to their chests as well as a lack of confidence
that test house expertise may also be valued by car manufacturers.
This leads to test houses maintaining a cost-intensive infrastructure albeit with
rather low capacity utilisation and insecure perspectives. The costs incurred
have therefore got to be added to test orders. As a result, there is a lack of
synergy effects.
Fig. 1
System Integration State of the Art [Fig. 1]
Vision
Everyone focuses on their core task.
Car manufacturers specify function scopes and check successful implementation.
Suppliers develop control devices rather than specifications or test tools.
Test houses concentrate on error recognition and support car manufacturers
and suppliers with their know-how, with test specifications and tools.
Vision: Outsourcing of System Integration Testing [Fig. 2]
What Needs To Be Done To Achieve This?
Fig. 2
Firstly, we should not count on revolutionary structural changes taking place
and therefore appropriate measures are required within today's structures or measures which constitute simple changes
in the distribution of roles. There will always be pressure on costs for suppliers with simultaneous pressure on increased
functionality. Whenever more functionality is requested without any regards to quality assurance, errors are produced which
customers can subsequently see.
In order to improve the current situation the following measures are important:
Definition Of Suitable Interfaces For Validation
Clear communication not only in terms of requirements but also on acceptance criteria. Typically, this means that car manufacturers define their requirements and additionally request how completion of these requirements should be proven. Car
manufacturers can check levels of implementation of a supplied device with appropriate documents / test reports. The test
house helps with error recognition by employing appropriate, coordinated methods.
63
30TH SEPTEMBER 2008
STUTTGART - GERMANY
Car manufacturers and suppliers need to agree clearly which scopes should be implemented and how realisation of these
scopes can be tested. Confidence in a supplier will only come about, in practice, if car manufacturers prescribe test processes
to suppliers or at least have detailed knowledge of these and are able to comprehend the results. Experience shows that you
cannot get around a detailed definition of test sequences. It is equally important to have a transparent test reporting system
which will also give information on resilience of a control device.
Choosing Important Test Scopes And Making The Right Choices
One quickly gains the experience that it would be too much effort to apply all kinds of possible tests for acceptance of a
control device or an entire on board supply system. Even in chip production you no longer have a 100% test coverage since
the effort involved, these days, would not justify the outcome.
It is therefore important to concentrate on the essential test sequences only, which can render a high error rate while involving a comparatively small effort. In the same way, defined test scopes should cover the requested requirements based on
the stages of construction.
Standardisation Of Test Scopes
In 10 years of MOST technology, many concepts and strategies have emerged to enable all but perfect validation. At the same
time, many different varieties exist not only as far as different car makers are concerned but also with different suppliers. It is
now time to evaluate these test scopes, to categorize them and to integrate them into one standard. Compliance test specifications are certainly a good basis for achieving this, even if these can only be a starting point in many ways.
Maintenance of Test Scopes
Of course, systems will evolve over time and this is particularly the case for the world of infotainment for cars. In order to
provide adequate validation for development, new scopes need to be taken into account as well as new findings.
And the most important findings are made by testers. Minimal modification or combination with the right stress scenarios
can give rise to surprising progress in error recognition rates. In order to make these findings known, testers have to be motivated and have to have the opportunity to give feedback in an uncomplicated fashion. This is particularly true for the role
of suppliers.
How To Go About It?
Application Recommendation
Application Recommendation for Core Compliance (see MOST Intranet) is an important step towards standardised procedure
in defining test scopes and test reports. It defines necessary interfaces in form of test specifications. Test evaluation and test
reporting: It defines processes such as how requirements can be displayed in test sequences and in this context it also collects
test scenarios independent of particular car makers.
Application recommendation has already yielded results in the area of physical layers. Scope core is still at the beginning and
refers to the testing of individual control devices, for now. In the medium term, application recommendation is certainly expandable to systems integration and application issues.
Executable Test Specifications
Experience from projects and from compliance specifications work has shown that where specification is solely done at a
document level, the display does not show sufficiently fine details which consequently leaves too much room for interpreting
data. This was one of the reasons for switching from flow chart to MSC in core compliance specification. But even with MSC
there is not always enough transparency. Above all, there are shortcomings in the specifications process which are due to the
fact that tests are firstly developed on paper and in theory. First findings are gained quite late during implementation or test
execution. Improvements are made at a late stage and are therefore difficult to plan. A solution is an executable test specification in form of a GFT, based on the test language TTCN-3. A theoretical design of a test sequence in a graph format can
64
FORUM
be quickly realised and tested against a control device or a simulation. Since the test itself can be displayed as GFT, findings
from practical experience can be integrated into the specifications phase.
The Test House As An Independent Authority
It is first and foremost in the interest of a test house to find the largest possible number of errors in the most efficient way.
Compared to the interest of suppliers, who want to integrate as many features as possible into their control devices while
keeping development costs as low as possible, a test house can focus its efforts on a standardised test process with corresponding tooling and a high degree of automation and a high error recognition rate. Furthermore, a test house can support
car makers in providing highly efficient and transparent validation. Success can be easily read off the key numbers which are
part of the test reports.
Benefits
Cost Reduction
The most important test scopes can already be realised by suppliers, with the support of test house expertise, as the case may
be. This leads to recognition of more errors at an earlier date.
Cost structures for the development of tests can be minimised by synergy effects such as standardisation independent of car
manufacturers, good capacity utilisation, support for suppliers and rollout of test tooling to suppliers.
Test solutions can be standardised. Not every supplier needs to develop his own test tool, in order to cover validation
scopes.
Outsourcing Of Testing
In future, car manufacturers can concentrate on specifying function scopes and monitoring of developments. Validation can
concentrate on sensitive issues of systems integration and provide quality assurance at the highest level.
Greater Transparency For All
Suppliers: Will gain a better understanding of which mistakes they have made, what car makers are really interested in, and
their problems will in turn be better understood by car makers. They will not have to invent large parts of the test scenarios
and test tools but can buy in this service and / or supported tooling.
MOST Technology will again be seen as a module which can be integrated into the development of a control device without much effort and
can now be validated at a high level.
CONTACT
• Car Manufacturers: Can concentrate on their main task in systems integration.
Will be able to trust suppliers more.
Will have independent experts with clear key figures on error recognition rates.
Will have a transparent overview of the state-of-the-art of technologies.
Can place test orders in a cost-efficient way.
• Test Houses: Will be taken seriously and will no longer be seen as a necessary and expensive evil and will no longer only
be consulted in the context of compliance testing when their expertise is absolutely indispensable. They will be able to
participate fully in an ongoing process of maturation, which is very important for acceptance of MOST.
• MOST Technology: Efforts for standardisation will result in greater
interoperability and will therefore generate a competitive advantage
Wolfgang Malek
Georg Janker
against competing technologies.
Ruetz System Solutions GmbH
Ingolstädterstrasse 18
80807 München
Germany
T +49 89 35610 190
F +49 89 35610 111
W www.ruetz-system-solutions.com
65
30TH SEPTEMBER 2008
STUTTGART - GERMANY
MO S T SERI ES PROJECTS EXPERIENCE
Error Handling Strategies for
a MOST Application Framework
Torsten Pech, Daimler AG (w/o image)
Andreas Vallentin, Daimler AG
1. Introduction
Today, high-end automotive infotainment systems - providing a vehicle’s navigation, entertainment and communication functions - are distributed systems, where control commands, audio/video and information content (e.g., IP-based data for web
browsing) are transmitted between different specialized devices over a MOST bus. As an example, such a system consists of a
so-called Head-Unit which provides the user interface for the driver, and several attached peripheral devices such as a satellite
tuner and a gateway to a user’s mobile multimedia player, which are controlled by the Head-Unit.
Usually, automotive infotainment systems are not safety-critical. However, the applications are highly interactive, for example
when browsing through the music titles of a mobile multimedia player. Errors such as message losses may have various effects
that are annoying for the user, like the delayed execution of a function, the display of wrong information, the unavailability
of certain functions up to a freeze of the application.
Therefore, in automotive infotainment systems error handling is mainly focussed on ensuring that the respective functionality
is provided to the user with an adequate responsiveness. An effective error handling contributes significantly to the perceived
quality of the system. Additionally, error handling is safety relevant when it comes to handling audio signal, as sudden loud
noises due to a failure of the communication network may cause a distraction for the driver. In future, error handling may
become even more important given the current trend to integrate assistance and infotainment systems.
Error handling has been discussed extensively in distributed systems, for example for safety critical systems, for ensuring data
consistency in database systems and for distributed algorithms (see, for example [7]). However, these mechanisms usually
require hardware support or increase the communications and processing requirements significantly. When specifying error
handling strategies it is important to take into account the properties of the application area and of the communication
network.
Due to the characteristics of the MOST bus with its specific physical layer (including the data-link layer) as well as the specific
characteristics of the drivers for the MOST bus, the NetServices (see [4]), and due to the fact that the MOST standard also
specifies the application layer with a specific syntax and semantic (e.g., for notification handling), an appropriate system-wide
error handling strategy is a critical aspect of an MOST application framework.
In Section 2 of this paper, we will discuss the different types of error that may occur in a MOST system and propose a classification based on their cause and probability. Based on this classification Section 3 will describe proven general error detection
and error handling strategies that define first mechanisms to recover from an error and second mechanisms for handling
errors that could not be recovered.
Because a discussion of error handling should be based on experiences with existing systems the discussion in this paper is
confined to MOST25 and its optical physical layer. Additionally, because of the limited space in this paper, specific error handling strategies for connection handling and the MOST High Protocol [1] are not discussed.
66
FORUM
2. Causes of Errors in a MOST System
Errors in a MOST system can occur for different reasons and will therefore have to be detected and handled on different layers
of a MOST device. For the discussion of the error handling we use following simplified 3-layered model of a MOST device
(see Figure 1).
Figure 1: Simplified 3-layered model of a MOST device.
Applications that are running on the application layer of a MOST
device pass their requests via the network layer, which includes the
MOST NetServices, to the physical layer that sends them on the
MOST bus. The answers to requests are read from the MOST bus
and sent through the physical layer, via the network layer back to
the application layer.
Following are the most common reasons for errors in a
MOST system:
• Message losses: Message losses are in a MOST system often
Fig. 1
caused by a full receive buffer of a device. Because of the single
receive buffer of the OS8104 Network Interface Controller [5] or its successor the INIC [6] single message losses are common if one are more devices send messages faster than the receiving device can currently read them from the receive buffer.
Therefore, also multiple message losses are not uncommon, if a device incurs a high communication load. Further message
losses may be caused by a high load of the application layer or errors in the higher layers of the communication stack.
• Transmission errors: Bit errors on the physical network can cause corrupted messages on a higher layer. However, because
of the optical physical layer of the MOST bus, bit errors are very rare (except for instable situations, for example during
start-up).
• Interrupted communication: An unlock on the MOST bus causes an interruption of communication. Unlocks are quite
common especially during the start-up of a device (e.g., during cranking). On higher layers an unlock may be perceived as
a burst of message losses.
• Configuration errors: Devices that join or leave a MOST system by opening or closing their bypass cause a change in the
system configuration, called an MPR-event. Until detected and handled, a configuration change will be perceived by the
remaining devices as different kinds of errors when a communication partner is not available anymore. Configuration
changes happen quite frequently (This will happen more often with an OS8104 Network Interface Controller [5] then with
the newer INIC [6].), for example during cranking of the system, where the voltage drop causes a reset of some devices,
while other devices continue to operate.
• Unavailability of device functions: Due to a high processing load, a problem of an external system or a device specific error,
a function of a device that is necessary to execute a user request may currently not be available. The probability of such
errors is very specific to the type of device. These errors should be signalled by the appropriate error responses over the
control channel and need to be handled on application layer.
• Message sequence errors and duplicate messages: These errors are mainly causes by the error recovery mechanisms (e.g.,
retries) themselves. Because of the design of the NetServices with a single sending queue, these errors are rather rare and
may be avoided when not using application level retries. However, sequence errors may occur if messages are handled by
different instances in a device, as is the case with application messages and configuration status messages.
• Device failure and implementation errors: Other kinds of errors may be caused by device failures and implementation errors, for example if a device sends wrong error messages. These errors often occur during system integration and testing
and should be found and fixed for the production-ready system. However, some errors may also occur in those systems,
for example because of unlucky timing constraints (e.g., race conditions). How far an error handling also targets the system integration phase has to be decided by the system integrator.
67
30TH SEPTEMBER 2008
STUTTGART - GERMANY
Unfortunately it is only possible to detect the root of the errors by their symptoms, so the error cause only can be determined
by an educated guess. Some errors may not be detected at all.
3. Error Detection and Handling
The MOST Specification [2] already defines some requirements for the signalling and handling of errors in a MOST system. For
example, Section 2.2.3.5.1 defines a detailed set of error responses for control messages. However, these requirements just
describe a general philosophy or mechanisms that are necessary to ensure the interoperability of a MOST system. It is up to
the system integrator to define a consistent error handling strategy.
3.1. Overview
Figure 2 shows the flow of actions for the error handling. Basically, this mechanism will be executed on every layer starting from
the physical layer. Often detected errors can already be handled
through the recovery strategy on the appropriate layer. Errors that
are not handled on one layer are passed on to the next higher layer.
Additionally, some errors (e.g., the unavailability of device functions)
can not be detected on the lower layers and therefore can be only
handled on a higher layer.
Fig. 2
Figure 2: State chart for error handling mechanisms.
The recovery strategy needs to be specific for different error classes, to reflect the possible reasons for such an error. Additionally, an implementation for error handling has to take into account that during error recovery an error of a different class is
detected and has to be able to switch to another error recovery mechanism while avoiding endless loops. However, we will
not discuss this aspect in this paper to keep the discussion more simple.
3.2. Physical Layer
Basic errors that occur on the physical connection and the data link layer of the MOST bus are handled by the physical layer. The MOST Network Interface Controllers already provide a mechanism to detect message losses through an ACK/NAK
mechanism included in the protocol of the MOST control channel. If a receiver does not acknowledge a message the sender
triggers a specified number of retries within a specified time interval. Note: while it is possible to avoid higher level retries
by specifying a large number of low level retries within a big time interval, this causes a high load on the bus and blocks the
sender for the respective time, thus increasing the probability of a deadlock.
Transmission errors are detected through a CRC (Cyclic Redundancy Check) mechanism and also cause low level retries. Because of the rare occurrence of transmission errors, it is usually not necessary to handle them on a higher layer.
Additionally, the physical layer provides a handling for an interrupted communication because of an unlock. After 70 ms or a
series of short unlocks the physical layer signals a critical unlock that leads to an error shutdown of the MOST bus. Therefore,
the error handling has to be able to deal with at least bursts of message losses of up to 70 ms.
3.3. Network Layer
The network layer handles provides further error handling through the NetServices and handles network changes.
Responsible for detecting and handling configuration changes is the Network Master. When detecting a network change
through an MPR-event, the Network Master triggers a network scan and reports the changes to all application in the MOST
system. The behaviour of the Network Master is specified to a large degree by the MOST Specification [2] in Section 3.1.3.3.
68
FORUM
However, the behaviour of the Network Master needs to be further detailed for a given system architecture. Especially if there
are multiple changes to the configuration during start-up and cranking, the stability of the Network Master is critical for a
stable system.
Optional mid level retries that are triggered by the NetServices can be used to expand the time interval covered by the low
level retries. They allow using a lower number of and a shorter time interval between the single low level retries thus increasing the performance. Together low and mid level retries should be able to deal with message losses that occur for the 70
ms before a critical unlock is caused.
3.4. Application Layer
Errors on a higher level of the MOST protocols, such as a missing response to a request with the OPType Get, can only be
handled by the application layer as they are not detected on the lower layers. Therefore, MOST devices should also implement
error handling mechanisms on the application layer, such as application level retries. Additionally, application level retries
may resolve situations, which otherwise would lead to a deadlock as they allow other requests that are currently in the send
buffer of the NetServices to be performed before the request is executed again. For an argument for application level error
handling see also the discussion for the end-to-end argument, which had a significant influence on the design of the Internet
protocols [3].
As one measure, the application layer should implement a timeout mechanism with respective error handling for the request
response mechanism defined by the MOST control protocol.
•
For requests to properties with the OPType Get/SetGet as well as for requests to methods with the OPType StartResult/
StartResultAck, the MOST Specification specifies a suitable timeout mechanism. (These values may be expanded for properties or methods with larger parameters.) If this timeout expires, an appropriate error handling shall apply. As a recovery
strategy, the application layer should perform one retry. If this retry fails the current request shall be aborted and the
application shall return to normal operation assuming a valid response.
A further responsibility of the application layer error handling is to handle the case that an error response is received for a
request. Error responses for the control protocol are defined in Section 2.2.3.5.1 of the MOST Specification [2]. The following
items give an overview of the error handling for important error responses.
•
The errors “FBlockID not available” (error code: 0x01) and “InstId not available” (0x02) indicate a configuration error.
Therefore, if a first application level retry has failed the device should update its registry information and perform another
retry if still applicable. If the second retry has failed the unavailability of the functionality should be signalled to the user.
• The further errors “FktID not available” (0x03) and “OPType not available” and the parameter errors (0x05 to 0x07), indicate a device internal problem or an implementation problem. In this case the application layer shall perform one retry.
• The handling of “Function specific” errors (0x20) should be defined in the function catalogue of the respective function.
If nothing is specified the same behaviour as for the last item should be performed as default.
• A temporary unavailability of a device function may be indicated by the errors “Busy” (0x40), “Not available” (0x41) or
“Processing error” (0x42). In this case a higher number of retries should be performed within a larger time interval, to
recover from the error.
69
30TH SEPTEMBER 2008
STUTTGART - GERMANY
4. Conclusion
In this paper we discussed the causes for errors in a MOST system and described a strategy for their detection and handling on different layers of a MOST device, including the application layer. While there may be different valid error handling
strategies, the error handling strategy described here has been successfully implemented in our MOST system architecture
and proven successful in existing series projects. With this paper we hope to raise the awareness for the importance of error
handling in a MOST system and to start a more detailed discussion regarding specific error handling mechanisms. As the error
handling in a MOST system should follow a uniform strategy, we believe that support for error handling should be included
in the standard software of an MOST application framework.
If in the future the MOST bus will also be used for driver assistance systems, for example to transmit video images of a camera
system, it may be necessary to define more elaborate error handling strategies for use cases that require a higher degree of
fault tolerance.
[1] MOST Cooperation: MOST High Protocol Specification, Rev. 2.2,
URL: www.mostcooperation. com, Aug. 2005.
[2] MOST Cooperation: MOST Specification, Rev. 3.0, URL: www.
mostcooperation.com, Jun. 2008.
[3] J. Saltzer, D. Reed, and D.D. Clark: End-to-End Arguments in
System Design, ACM Transactions on Computer Systems, Vol. 2,
No. 4, Nov. 1984, pp. 277-288.
[4] SMSC Cooperation: MOST NetServices Layer I, Wrapper for
INIC; V2.1.x, User Manual Specification, URL: www.smsc-ais.com,
Jul. 2008.
[5] SMSC Cooperation: OS8104 – MOST Network Transceiver, Final
Product Data Sheet, URL: www.smsc-ais.com, Jan. 2003.
[6] SMSC Cooperation: OS81050 Data Sheet, URL: www.smsc-ais.
com, Aug. 2007.
[7] G. Tel: Introduction to Distributed Algorithms, Second Edition,
Cambridge University Press, Feb. 2000.
70
CONTACT
References
Torsten Pech
Andreas Vallentin
Daimler AG
HPC: 059-X908
71059 Sindelfingen
Germany
T +49 7031 90 48890
E alexander.leonhardi@daimler.com
E torsten.pech@daimler.com
E andreas.vallentin@daimler.com
FORUM
Uwe Hackl, AUDI AG
Abstract
In 2000, AUDI joined the MOST Cooperation to establish a common MOST standard as a basis for its second infotainment generation. The outcome of this standardization work, the AUDI Multimedia Interface (MMI) was successfully launched in 2003 with the
market introduction of the A8. This MOST based infotainment architecture has become a platform and was adapted to different
markets, different cars and different applications within the following couple of years. Today this platform is installed in the models
A8, A6, A5, A4 and Q7.
Driven by upcoming infotainment requirements, AUDI decided to design a new architecture. The integration of multiple functionalities into individual devices brought the advantage of cost reduction as well as reducing the overall weight. Although a significantly
new architecture was brought into being, a couple of existing MOST
devices could easily been migrated to this new architecture. Also the
migration was taken as a chance to introduce the INIC, Multichannel
Audio, Compliance Testing and a more recent MOST Specification, participating in these innovations. To provide the customers a modern infotainment system for tomorrow, the infotainment system has to be built
on architecture sufficient for their needs. It has become an art to incorporate all the quality aspects, development processes, feature requirements and the growing speed of the consumer electronic development
into an infotainment project.
AUDI decided to fully support MOST again as the infotainment backbone to meet its future challenges. As the world goes digital, the internet
grows and the networking increases the customer value, MOST150 is a
viable answer. Through the development over the next few couple of years, AUDI will set up its next infotainment generation based
on this network.
Introduction
In 2000, AUDI joined the MOST Cooperation to establish a common MOST standard as a basis for its second infotainment generation. This generation should substitute the first generation, which was identified by a highly integrated so called „2DIN factor“ component. From the point of networking, it was possible within the first generation e.g. to connect a CD-Changer or a sound system.
But the streaming data was transferred completely analogue between the components.
MMI2G
As an outcome of this standardization work, the MOST based „AUDI Multimedia Interface (MMI)“ was successfully launched in 2003
with the market introduction of the A8. This system embraced the following components: Head-Unit, AmFm-Tuner, CD-Drive, or
CD-Changer, Telephone, Navigation, TV-Tuner, Speech-Dialog-System, Amplifier, MOST/CAN Gateway. Each of them was designed
as a separate (MOST-) Device. Without the joint forces of the MOST Cooperation, it would have been an infeasible task to define,
implement and test all the necessary items where the list reaches from the FOT, Transceiver, Ring Diagnosis and the Network- and
Power-Management up to the APIs like Telephone, Phonebook, Navigation, TMC, AmFm, CD, Amplifier - just to mention some of
71
30TH SEPTEMBER 2008
STUTTGART - GERMANY
them. Here it became clear that MOST is more than a chip and a specification. MOST is also a design pattern. Once understood by
car makers and their suppliers, it makes it possible to implement a distributed system in an efficient way. The practical use even of a
subset of the standardization work forms a common language between all the participants.
Later this MOST based infotainment architecture has become a platform and was adapted to different markets, different car models
and different applications within the following couple of years. In addition to a lot of single ECU enhancements, completely new
systems were also integrated using the existing components. Until now this MMI2G platform has been installed in the car models
A8, A6, A5, A4 and Q7. E.g. with the Asia System, an existing Asia Navigation was ported to the given HMI. With the latest A6, a
DOT-Matrix Head-Unit was introduced to cover the low entry market. Here the tuner as an audio source was implemented on the
same device like the MOST Timing Master. This has some conceptual implications as one can imagine.
MMI3G
Already soon after the market introduction, it pointed out that further requirements will come up, and due to the technological
progress a new architecture would make sense. AUDI decided to design a new architecture, the third generation of infotainment
systems – MMI3G. The concept of the MMI3G is to split the basic features into two ECUs: The MainUnit and the RadioUnit. While
the RadioUnit comprises all the radio tuner functionalities as well as a basic audio amplifier, the MainUint comprises all the media and
video aspects, speech recognition, navigation and telephony. The high integration of the wide variety of ECUs into just two components reduces weight and power consumption. The now available computing power within the MainUnit can be shared by different
applications, like speech recognition, navigation, telephone, audio processing and by a lot of media codecs from mp3 up to DVD-Video. Today the MMI3G covers all functionalities from MMI2G and additionally
7“ WVGA Display, DVD-Video including multichannel audio, SD-Cards,
mp3, WMA, AAC, a HDD juke box, full word speech recognition, economical route navigation, 3D Navigation with terrain model – again just
to mention some of them.
Although a significantly new architecture was brought into being, a
couple of existing MOST devices could easily been migrated to this new
architecture. The car model dependent sound systems as well as the remaining devices not fitting into the highly integrated MMI3G, were not
changed. Hence, a CD-Changer, a TV Tuner and a couple of Amplifiers
were used in form of COPs. Since the MMI System has to be integrated
into several car models, the car model dependent gateways also remain the same. Once again it became clear that MOST is a well
known basis for changing parts of the infotainment system while others remain unchanged. One of the prerequisites doing so is the
API philosophy of MOST. Although a lot of ECUs which communicated via MOST within the MMI2G were integrated into the MMI3G
MainUnit, the communication pattern was kept the same. So a lot of internal applications of the MainUnit are „talking“ MOST, even
if no MOST Bus is involved hereby.
Since the basic applications are well defined, these APIs are seen as a stable interface working in different architecture environments.
On the other hand, MOST provides the necessary flexibility in extending the FBlocks to specific needs. Furthermore it is possible to
define whole FBlocks from scratch proprietary. AUDI makes use of both. Whenever the schedule constraints allow a simultaneous
standardization of APIs it is worth to benefit of that opportunity. When using an already standardized API, often it is necessary – and
fortunately possible with MOST – to enhance it. Even using proprietary definitions or whole proprietary FBlocks, one takes advantage
of generic mechanisms and definitions like General Functions, Notification Mechanisms, and Network Administrations and so on. As
an example, the Software Download within the MOST Network is done locally, using a CD. Hence no gateway is involved and hence
none of the mechanisms of CAN or Diagnosis. Since this has not yet been subject to standardization, AUDI created a proprietary
FBlock has been and is used already until today.
72
FORUM
During migration to the MMI3G several aspects were able to be improved. Due to our investigations and „lessons learned“ we
realized the network stability is one of the most crucial items for a successful implementation of the MOST based applications.
The development was based on the most recent MOST Specification 2V4 at that time, making the compliance process possible.
Today every MOST device developed for AUDI has to pass through the compliance process incorporating physical layer compliance
as well as core compliance and extended core compliance.
However, the most important MOST change from MMI2G to MMI3G was the introduction of the INIC technology. The core devices
MainUnit and RadioUnit were designed using the OS81050. A roll out of this technology over new developments projects continues
to take place at this time.
Another major change was the introduction of the DVD. Until then the CD was the sole medium, hence only stereo audio was
required. Now the advantage of multichannel audio is brought to the customer and – transported over MOST – it became necessary
to introduce the „Generic PCM“ streaming format. In addition, the DVD content owner requires some form of content protection
when transferring the content over digital networks. To fulfill both of these requirements simultaneously, AUDI implemented
multichannel audio as a special case from DTCP protected multichannel audio. In this special case, no authentication happens and
the DTCP information denotes the content as „copy freely“ and the audio is not encrypted. This congruence together with the
implementation of „Digital Transmission Content Protection (DTCP)“ in all audio amplifiers makes the architecture „DTCP ready“.
Once a specific codec requires a content protection for some kind of audio, DTCP can be enabled easily.
Next Steps
To provide the customers a modern infotainment system for tomorrow, the infotainment system has to be built on architecture
sufficient for those needs. Several aspects can be foreseen.
CONTACT
1.) The entertainment world grows as much as the Consumer Electronic world does. Video, high definition video, and data broadcast
must be supported. In addition the customers preferred method of recording entertainment data must be supported too. Moreover the broadcast of audio and video will bring an added value through the additional data services included within the broadcast
streams. All these data streams have to be brought through the network depending on the placement of receiver and decoder.
2.) The connecting of the home and the online connection via provider requires an interfacing of the wireless world to the car
network.
3.) The interconnections between functions from the MOST based infotainment domain have interacted with applications within
other domains.
4.) The world goes digital. From the content providers and their guardians there is the clear statement that the so called analog
hole will be closed by their adopter’s agreements to get control of the whole data flow and storage. This digital world as well as the
demand for growing bandwidth will require additional computing and graphic performance as well the ability to protect this content
in an appropriate manner. Due to the restricted resources, all of this data has to be scaled to the customer needs, e.g. large or small
displays.
AUDI decided to fully support MOST again as the infotainment backbone to meet its future challenges. As the world goes digital, the
internet grows and the networking increases the customer value, MOST150 is a viable answer, where the change is limited to the
technical development, keeping the production process with the POF in the
harness as it is today. While all sinks and sources were synchronized to the
Dipl.-Inform. Uwe Hackl
MOST Master clock in the past, this paradigm can change with MOST150,
AUDI AG
where the sinks are synchronized to the sources, and MOST just transports
85045 Ingolstadt
Germany
the data. Through the development within the next few couple of years,
T +49 841 89 41370
AUDI will setup its next infotainment generation based on this network.
E uwe.hackl@audi.de
W www.audi.de
73
30TH SEPTEMBER 2008
STUTTGART - GERMANY
Thank you for attending the MOST Forum 2008.
We are looking forward to meeting again
at future events.
74
FORUM
75
organized by
qaqadu events gmbh
www.mostforum.com

Conference Proceedings

Transcription

Similar documents

MFHutton

RHS AND CRYROP - Redlands High School

TruPay HR Forum.cdr

McGuffey`s 3rd Reader - Eclectic Education Series

NCHN Discussion Forum [SETUP INSTRUCTIONS] The NCHN

4th Energy Council of Bosnia and Herzegovina with

Mobiletron - moocreations

ILA Conference Center, GOLF Thursday, 2 June 2016

p 4 - 2mpower.us

GNYADA Sales Academy - Greater New York Automobile Dealers

AUTOSAR How to deal with non-functional properties Andreas L¨