65061-8 U1+U4_R25mm

14.01.2011

10:12 Uhr

Seite 1FRANZISELECTRONICS LIBRARY
THE AUTOMOTIVEMULTIMEDIA NETWORKMOST (Media Oriented Systems Transport) isa multimedia network technology developed
to enable an efficient transport of streaming,
packet and control data in an automobile.
It is the communication backbone of an

infotainment system in a car. MOST can also
be used in other product areas such as driverassistance systems and home applications.

MOST is a communication system with a new, flexible architecture, used bymany different manufacturers. It is the most widely used multimedia
network in the automotive industry.
In 2010, more than 100 car models are already equipped with MOST Technology. MOST defines the protocol, hardware, software and system layersthat are necessary for the high-performance and cost effective transport ofrealtime data in a shared medium. MOST Technology is developed andstandardized within the MOST Cooperation through a joint effort of carmakers and their suppliers. It is now evolving into a third generation with
MOST150 Technology.
The MOST Cooperation commissioned this updated book with the goal of
making it easier to understand and use MOST Technology. The authors of
the book work for carmakers, suppliers and scientific institutes. The
emphasis of the first part of the book is the MOST standard itself. After describing the organization of the MOST Cooperation, the general communication architecture of an automobile using MOST is presented. Then thechapter “Survery of the System Architecture” gives an overview of MOST
Technology. The most important aspects of the technology are then presented
in detail in subsequent chapters.

EDITOR: PROF. DR. ING. ANDREAS GRZEMBA

THE AUTOMOTIVEMULTIMEDIA NETWORKFROM MOST25 TO MOST150

The book is aimed at engineers at suppliers and carmakers that want to getstarted with MOST Technology. It also provides an overview of an effective
communication architecture to interested engineers outside the automotive industry.

EUR 49,95 [D]FRANZISISBN 978-3-645-65061-8

Visit our website: www.franzis.de65061-8 Titelei:X

19.01.2011

16:13 Uhr

Seite 1

Electronics LibraryMOST

65061-8 Titelei:X

19.01.2011

16:13 Uhr

Seite 2

65061-8 Titelei:X

19.01.2011

16:13 Uhr

Seite 3

ELECTRONICS LIBRARYEDITOR: PROF. DR. ING. ANDREAS GRZEMBA

THE AUTOMOTIVEMULTIMEDIA NETWORKFROM MOST25 TO MOST150

FRANZIS

65061-8 Titelei:X

19.01.2011

16:14 Uhr

Seite 4The MOST System
This book is based on the MOST Specification Version 3.0 E2, 07/2010. Since the specification is under constantdevelopment there could have been changes from what is described in the book. Should there be any differences
between the book and the specification, the specification should be followed. The latest version of the specification
can be found at www.mostcooperation.com.

© 2011 Franzis Verlag GmbH, 85586 Poing
All rights reserved, including photomechanical reproductions and storage on electronic media. Reproduction anddistribution as photocopies, on any data carrier or in the internet, especially as PDF, requires the explicit permissionof the publisher, all violations will be prosecuted.
Most of the product names of hardware and software as well as business names and corporate symbols mentioned
in this publication are normally also registered trademarks and should be considered as such. Product names
mentioned in this publication follow primarily the notation of the producers.
Circuits and applications presented in this publication are developed and tested with maximal accuracy. Anyway the
publisher makes no warranty with respect to the accuracy of the book and the software. The publisher and theauthor assume no liability for incorrect indications and their consequences.
Typesetting: Machelett Software & Consulting, Luise-Riegger-Str. 30, D-76137 Karlsruhe
art & design: www.ideehoch2.dePrinting: Bercker, 47623 Kevelaer
Printed in Germany

ISBN 978-3-645-65061-8

5

Preface to the second edition
The first edition of this book was released in March 2008 and based on the first
generation MOST25 (MOST Specification 2.4). It operates at 25 Mbps. Now, thesecond edition covers additionally the second and the third generation. MOST is theabbreviation for Media Oriented Systems Transport.
With the MOST Specification Rev. 2.5 for MOST50 – the second generation – theMOST Cooperation doubles the bandwidth for automotive infotainment solutions
from 25 to 50 Mbps. The MOST Specification of Electrical Physical Layer Rev. 1.1
is an additional key specification that enables data transmission over an unshielded
twisted pair (UTP) of copper wires while meeting the stringent automotive electromagnetic compatibility requirements.
MOST150 is the third generation offering a bandwidth, of 150 Mbps. With thetransmission over legacy POF/LED optical physical layer MOST150 offers asmooth migration from MOST25 and MOST50 allowing carmakers to continue to
use POF and LEDs as light sources. In addition to higher bandwidth MOST150 features an isochronous transport mechanism to support extensive video applications,as well as an Ethernet channel for efficient transport of IP-based packet data. This
channel carries legacy Ethernet packets (according to IEEE 802.3) without change.
Thus, the new generation of MOST provides the automotive-ready physical layer
for Ethernet in the car. This way, MOST will be open to a broad variety of IP based
applications. It even allows to adjust the bandwidth of conventional streaming connection on the one hand and the IP communication on the other according to thecorresponding requirements. Besides, MOST150 still supports the well-known
asynchronous channel to ensure backward compatibility of MOST25 applications.
With MOST150, audio and video signals can be transported with high bandwidth
efficiency and without any overhead for addressing, collision detection/ recovery or
broadcast. Multiple high definition (HD) video streams and multi-channel surroundsound with premium quality of service can be transmitted, while simultaneously
moving high loads of packet data around.
MOST network needs to support digital audio, video and data services equally:High QoS Synchronous (PCM audio …)

High QoS Isochronous (MPEG Transport Streams, audio and video over IP …)

High performance Packet with IP support

Realtime Control

6Preface

The number of vehicle models relying on the MOST infotainment backbone has
now hit the one hundred mark. This fast implementation growth rate with a total of
100 vehicle models on the road today reflects the practical suitability and reliabilityof MOST. Only three years after the MOST Cooperation was founded in 1998, thefirst MOST car was introduced in 2001. The following year, 13 more models implemented the MOST infotainment backbone. In October 2007, the leading network
technology had found its way into 50 car models, climbing to 68 models in March,
2009. Just one year later there are 50% more models on the road as MOST Technology spreads into the mass market.
Asian carmakers presented their first vehicles with MOST inside in 2007. Today,
there are 22 models manufactured by Asian automakers with MOST built in. MOST
Technology is now heading to the American continent with the first US carmakerworking on future vehicles that incorporate the MOST network.
MOST25 Technology has established itself in the European and Korean markets.
The Japanese and US markets prefer MOST50.
Now the newest Specification Rev. 3.0 for MOST150 is on the way to production.
Audi and Daimler will be the first carmakers to integrate MOST150 into series production vehicles.
The second edition has a new structure. Whereas the first edition, MOST also ranks
to the in-car communication systems, the second edition focuses solely on MOST.

Acknowledgements
I would like to thank my co-authors for spending their precious time to cooperateon this book and thus make it possible at all and to all members of the MOST Cooperation Steering Committee, who initiated and actively supported the second edition.
I also owe thanks to the coordinator of the MOST Cooperation, Mr. Wolfgang Bottfor the comprehensive support and Mr. Renato Machelett for the complete proofreading of the script.
Finally, I would like to thank Franzis publishing house for their many ways of contributing to this book.
January 2011
Karlsruhe

Deggendorf

MOST Cooperation

Andreas Grzemba (Editor)

7

Preface to the first edition
The automotive industry can look back on nearly 20 years of experience using incar communication systems. The development started with the CAN-Bus, which
has been used in production vehicles since the 1990s. The infotainment sector incars has developed rapidly within the last few years. Where an AM/FM tuner was
initially sufficient, many vehicles are now equipped with high-grade sound andnavigation systems. This also increases the number of devices involved – radio, cell
phone, CD changer, navigation system, voice operation and an additional multichannel amplifier supplement the primary systems. These devices must interact inconcert with each other and can only be controlled via a central operating surface toensure drivers are not unnecessarily distracted. The bandwidth of the CAN-Bus,
which can only move control signals, but no audio and video signals, is no longer
sufficient for these demands.
MOST, Media Oriented Systems Transport, a communication system with a new,flexible architecture, used by many different manufacturers, was developed to meetthese demands. It can transmit audio signals synchronously, as in telephones, and is
the most widely used multimedia system in cars today.
MOST technology is the result of the collaboration of car makers and suppliers,
working to establish and refine a common standard within the MOST Cooperation.
The founding fathers of the MOST Cooperation constitute the steering committee,
the managing body. All companies interested in the system can, however, collaborate in working groups. Chapter 1 introduces the Cooperation.
The MOST system not only comprises all layers of the Open System Interconnect(OSI) Reference Model for communication and computer network design, but also
standardizes the interfaces with the applications (e.g., an AM/FM tuner), which aredefined as function blocks. Their implementation is described by example interaction models. In addition, the encoding of the audio and video signals is part of thespecification. The system designer is thus able to design multi-media systems on arelatively high abstraction level.
This book is an introduction to the MOST technology. It cannot, however, replace
the work with the specifications. The basis for this book is the MOST specification
2.4, taking into account further developments. The current specifications can befound at the MOST Cooperation website http://www.mostcooperation.com.

8

Preface

The book is divided into two parts.
Part 1 deals with the MOST standard. After introducing the structure of the MOST
Cooperation, the communication architecture in the vehicle is presented for classifying the MOST Technology. Chapter 3, System Architecture, provides an introduction into the technology. The following chapters describe the most important aspects in detail.
Part 2 deals with the application of the MOST Technology. First, development
tools are introduced. The next chapter explains the structure and implementation ofa simple MOST system by means of these tools. This part then describes the basic
structure of MOST gateways, the handling of MOST components and the use of
MOST in current production vehicles. The last chapter describes the sound systems
used in cars.
The appendix comprises a list of abbreviations, a glossary with the most important
terms from the world of MOST, as well as a comparison between MOST, Ethernet
and IEEE1394. A short survey of the other communication systems currently usedin cars may contribute to a better understanding of the MOST technology. In thecontext of gateways, it is mainly the CAN-Bus and Bluetooth which are of interest.
I hope that this book will contribute to widely disseminating MOST Technology
and that it will be a useful reference work for designers and users. MOST is a system which is subject to constant improvements and further developments. Ideas orcomments concerning this book will be gratefully accepted at the e-mail address
andreas.grzemba@fh-deggendorf.de.

Acknowledgements
I would like to thank my co-authors for spending their precious time to cooperateon this book and thus make it possible at all.
My further thanks go to all members of the MOST Cooperation Steering Committee, who initiated and actively supported the project.
I also owe thanks to Mr. Josef Berwanger of BMW for checking through chapter
FlexRay, Mr. Roland Trißl of SMSC Europe for proof-reading chapter 9, Mr.
Matthias Karcher of SMSC Europe, Dr. Carsten Kellner of Vector Informatik forcooperating on chapters 14 and 15, as well as Mr. Jochen Klaus-Wagenbrenner ofHarman Automotive Division and Mr. Martin Arend of BMW for proof-reading
chapter 16.

Preface

9

I would particularly like to thank Mr. Robert Reiter of BMW for his many ideas andsuggestions, Dr. Christian Thiel, Mr. Armin Schmidt and Mr. Henry Muyshondt,
and their colleagues of SMSC, as well as Dr. Alexander Leonhardi of Daimler forthe complete proof-reading of the script.
I would also like to thank the translators for translating the book into English.
Finally, I would like to thank my wife Jana for the first thorough correction of thescript and Mrs. Astrid Lehmann and her colleagues at Franzis publishing house for
their many ways of contributing to this book.

Deggendorf, January 2008
Andreas Grzemba(Editor)10

Preface

The authors of the book in alphabetical order:

Dr.-Ing. Steffen Abbenseth
VOLKSWAGEN AG

Chapter 14

Dipl.-Ing. (FH) Frank Bähren
Harman Automotive Division

Chapter 9

Dipl.-Ing. (FH) Patrick Blum
Harman Automotive Division

Chapter 13

Dr.-Ing. Wolfgang Bott
Ingenieurbüro BOTTCO

Chapters 3, 12

Dr. Simon Burton, BEng. (Hons), Phd.
Vector Informatik GmbH

Chapter 10

Dipl.-Ing. (FH) Markus Dittmann
Harman Automotive Division

Chapter 16

Dr.-Ing. Volker Feil
Daimler AG

Chapter 8

Prof. Dr.-Ing. Andreas Grzemba
FH Deggendorf

Chapters 2, 5, 9, 11, 15, 17
Appendix B, C, D

Dr.-Ing. Dieter Jurzitza
Herrmann Ultraschalltechnik GmbH

Chapter 16

Dipl.-Ing. (FH) Stefan Kerber
SMSC Europe GmbH

Chapter 9

Dr.-Ing. Thomas Kibler
Daimler AG

Chapter 6

Preface
Dipl.-Physiker Jochen Kirschbaum
BMW AG

Chapter 7

Dr. Rainer König
Daimler AG

Chapter 1

Dipl.-Ing. Joachim Leonhard
K2L GmbH

Chapter 17

Dr. Alexander Leonhardi
Daimler AG

Chapter 4

M.Sc. CS Markus Nordgren
SMSC Sweden

Section 5.8.2 - 5.8.4

Dipl.-Ing. Tilo Nothacker
Daimler AG

Chapter 6

Dipl.-Ing. Stefan Poferl
Daimler AG

Chapter 6

Dipl.-Ing. (FH) Armin Schmidt
SMSC Europe GmbH

Chapter 10

Dipl.-Ing. (FH) Alexander Schneidenbach
AUDI AG

Chapter 14

Dr. M. Eng. Andreas Schramm
BMW AG

Chapter 15
Appendix A

Dipl.-Ing. Harald Schöpp
SMSC Europe GmbH

Chapter 18

Dr.-Ing. Christian Thiel
SMSC Europe GmbH

Chapter 1

11

12

13

Contents
1

MOST Cooperation
1.1
1.2
1.3
1.3.1
1.3.2
1.3.3
1.3.4
1.3.5
1.4

2

3

43

Structure ..........................................................................................43
MOST Specification......................................................................... 44
MOST Dynamic Specification .......................................................... 46
MOST Function Catalog .................................................................. 46
MOST Compliance Test Specifications ........................................... 46
Further Specifications, Guidelines and Cookbooks ......................... 48

Application Framework
4.1
4.2
4.2.1
4.2.2

29

MOST Layer Model ......................................................................... 29
Application Framework .................................................................... 30
New isochronous transmission mechanisms for MOST150 ............ 33
Network Services............................................................................. 34
MOST Data Link Layer ....................................................................34
MOST Frame...................................................................................34
TimingMaster, TimingSlave ............................................................. 35
Physical Layer ................................................................................. 36
Optical Physical Layer ..................................................................... 37
Electrical Physical Layer.................................................................. 38
MOST Device ..................................................................................38
Network Management .....................................................................39
NetBlock ..........................................................................................40
PowerMaster ................................................................................... 40
NetworkMaster; NetworkSlave ........................................................ 40
ConnectionMaster ........................................................................... 41
Error Management and Diagnosis ................................................... 41
Transmission of Multimedia Data .................................................... 42

Survey of the MOST Specifications
3.1
3.2
3.3
3.4
3.5
3.6

4

Motivation and History .....................................................................21
Fast Standardization........................................................................ 23
Structure and Specification Work .................................................... 24
The Steering Committee.................................................................. 24
The Administrator ............................................................................ 25
The Technical Coordination Group.................................................. 25
The Working Groups ....................................................................... 26
The Technical Coordinator .............................................................. 26
The Compliance Verification Program ............................................. 26

Survey of the System Architecture
2.1
2.2
2.3
2.4
2.5
2.5.1
2.5.2
2.6
2.6.1
2.6.2
2.7
2.8
2.8.1
2.8.2
2.8.3
2.8.4
2.9
2.10

21

49

Device Model...................................................................................49
Application Protocol......................................................................... 51
Data Format.....................................................................................51
Dynamic Behavior ........................................................................... 59

14

Contents
4.3
4.3.1
4.3.2
4.3.3
4.3.4
4.3.5
4.4
4.4.1
4.4.2
4.4.3
4.4.4

5

MOST Protocols
5.1
5.1.1
5.1.2
5.1.3
5.2
5.3
5.3.2
5.3.3
5.4
5.4.1
5.4.2
5.4.3
5.5
5.5.1
5.5.2
5.5.3
5.6
5.7
5.8
5.8.1
5.8.2
5.8.3
5.8.4
5.8.5

6

MOST Function Blocks .................................................................... 66
Structure of a Function Block........................................................... 66
Function Classes ............................................................................. 67
Function Interfaces .......................................................................... 69
System FBlocks...............................................................................69
Administration of Streaming Connections........................................ 74
Standardized Application Interfaces ................................................ 77
Function Library............................................................................... 77
Common Functions (GeneralFBlock) .............................................. 79
Application Interfaces ...................................................................... 79
Example of Use (AuxIn)................................................................... 82

MOST Frame...................................................................................87
MOST25 Frame............................................................................... 87
MOST50 Frame............................................................................... 89
MOST150 Frame............................................................................. 90
MOST Data Transport Mechanisms ................................................ 93
Streaming Data................................................................................ 93
Synchronous Data ...........................................................................94
Isochronous Data ............................................................................94
Packet Data Channel....................................................................... 97
Packet data protocol for MOST25 and MOST50 ............................. 97
Packet data protocol for MOST150 ................................................. 98
Arbitration algorithm ........................................................................ 98
Control Channel............................................................................... 99
CMS for MOST25 ............................................................................ 99
CMS for MOST50 .......................................................................... 104
CMS for MOST150 ........................................................................ 106
Summary ....................................................................................... 108
Addressing..................................................................................... 109
Higher Protocols ............................................................................ 112
MOST High Protocol (MHP) .......................................................... 112
Ethernet over MOST...................................................................... 117
MOST Isochronous QoS IP (Streaming) ....................................... 118
MOST Ethernet with QoS IP.......................................................... 119
MAMAC ......................................................................................... 120

Physical Layer
6.1
6.2
6.2.1
6.2.2
6.3
6.4
6.4.1
6.4.2
6.4.3
6.5
6.5.1
6.5.2

87

121

Introduction.................................................................................... 121
POF Plastic Optical Fibers ............................................................ 122
Basic Principles ............................................................................. 122
Polymer Fibers – Properties and Advantages ............................... 124
Contacting of PMMA Fibers........................................................... 127
Opto-Electronic Transceivers ........................................................ 129
LED Transmitter Devices............................................................... 129
PIN Photodiodes............................................................................ 131
Transceiver Housing and Connectors ........................................... 131
System Considerations for the MOST Physical Layer ................... 135
Basic Principles of Electrical and Optical Parameters ................... 135
Optical and Electrical Requirements.............................................. 140

Contents
6.5.3
6.5.4
6.6

7

8

10

175

Overview ....................................................................................... 175
MOST NetServices........................................................................ 176
Models of MOST NetServices ....................................................... 177
Dependencies on MOST Specification Baseline ........................... 177
Modules of the MOST NetServices ............................................... 177
Layer I Version 1.x......................................................................... 177
Layer I Versions 2.x and 3.x .......................................................... 180
Layer II Versions 1.x, 2.x and 3.x .................................................. 183
Integration of the MOST NetServices onto the Target Platform..... 187
Callback Functions ........................................................................ 187
Main Loop Architecture.................................................................. 188
Multitasking Architectures.............................................................. 189
System Management Module ........................................................ 190

MOST Interface Controller
10.1
10.2
10.2.110.2.2
10.3
10.3.1
10.3.210.4
10.4.1

167

Network Fault Detection ................................................................ 167
Ring Break Diagnosis .................................................................... 167
Sudden Signal Off/Critical Unlock Detection ................................. 168
Localizing the Origin of Coding Errors ........................................... 169
Electrical Control Line.................................................................... 169
Device Fault Diagnosis.................................................................. 171

Network Service
9.1
9.2
9.2.1
9.2.2
9.3
9.3.1
9.3.2
9.3.3
9.4
9.4.1
9.4.2
9.4.3
9.4.4

155

System Initialization....................................................................... 155
System Query................................................................................ 155
Central Registry............................................................................. 156
Dynamic Addressing...................................................................... 159
Examples of System Starts............................................................ 159
Notification..................................................................................... 160
Power-Down .................................................................................. 162
Fault Types.................................................................................... 162
Network Faults............................................................................... 163
Device Faults caused by Temperature and Voltage Violations...... 164

Network Diagnostics
8.1
8.1.1
8.1.2
8.1.3
8.1.4
8.2

9

Power Budget ................................................................................ 143
Timing Requirements .................................................................... 145
Alternative Transmission Media..................................................... 147

Network and Fault Management
7.1
7.1.1
7.1.2
7.1.3
7.1.4
7.2
7.3
7.4
7.4.1
7.4.2

15

191

MOST Network Interface Controller and MOST Device ................ 191
MOST Network Interface Controller Families ................................ 192
INIC ...............................................................................................192
NIC193The INIC Family............................................................................. 194
Members ....................................................................................... 194
Overview of Features .................................................................... 195
Interfaces to the INIC..................................................................... 195
Available Interfaces ....................................................................... 195

16

11

12

Contents
10.4.210.4.310.4.410.5
10.5.1
10.5.2
10.6
10.7
10.8
10.9
10.10
10.11
10.12
10.13
10.14
10.14.1
10.14.2
10.14.3
10.14.4
10.14.5
10.14.6
10.14.7
10.14.8

Interfaces from Software Perspective............................................ 198
Ports, Sockets and Connections.................................................... 200
Port Message Protocol .................................................................. 202
Protection, Encapsulation and the EHC ........................................ 203
Interaction between INIC and the EHC.......................................... 203
The Watchdog Functionality .......................................................... 205
Configuration through Configuration String ................................... 205
Control Port ................................................................................... 206
Streaming Port............................................................................... 207
SPI Port ......................................................................................... 208
Transport Stream Interface (TSI)................................................... 208
MediaLB Port................................................................................. 208
Power Management ...................................................................... 212
Intelligent Muting ........................................................................... 213
Network Interface Controller (NIC) ................................................ 213
Available Interfaces ....................................................................... 213
Serial Operation............................................................................. 215
Parallel Operation of CP and SP ................................................... 215
Possible Configurations (Serial/Parallel) ....................................... 215
The Basic Configuration of a NIC .................................................. 216
Interfaces for Control Data in NICs................................................ 217
Interfaces for Streaming Data in NICs ........................................... 217
Interfaces for Packet Data in NICs ................................................ 217

Tools

219

11.1
11.2
11.2.111.2.2
11.3
11.4
11.4.1
11.4.211.4.311.4.411.5
11.5.1
11.5.2

Overview ....................................................................................... 219
Specification Tools ........................................................................ 220
MSC Editor .................................................................................... 220
MOST Editor.................................................................................. 220
Simulation and Analysis Tools....................................................... 223
Rapid Prototyping Tools ................................................................ 224
Plug-in for Simulation and Analysis Tools ..................................... 224
Hardware platform for Rapid Prototyping and Evaluation.............. 224
PC Tool Kit .................................................................................... 225
System components ...................................................................... 226
Hardware Development Tools ....................................................... 226
INIC Remote Viewer...................................................................... 226
MediaLB Analyzer ......................................................................... 227

Compliance Tests
12.1
12.2
12.2.112.2.2
12.3
12.4
12.5
12.6

229

Objectives of Compliance Tests .................................................... 229
Organization of the Compliance-Process ...................................... 230
Authorities for the Compliance Process......................................... 230
Workflow of the Compliance Process ............................................ 231
Physical Layer Compliance Tests.................................................. 232
Core Compliance Tests ................................................................. 234
Profile Compliance Tests............................................................... 236
Interoperability Tests ..................................................................... 237

Contents
13

Testing MOST based Infotainment Systems
13.1
13.2
13.3
13.3.113.3.213.3.313.3.413.3.5
13.4
13.5
13.6
13.7

14

15

16

257

Introduction.................................................................................... 257
MOST150 Evolution Approach ...................................................... 257
Hardware Evolution ....................................................................... 258
System Software Evolution............................................................ 259
MOST25/MOST150 Bridge Concept ............................................. 261
General Bridge Architecture .......................................................... 261
Addressing Concept ...................................................................... 262
Network Management ................................................................... 263
PCM Data Bridging........................................................................ 265

Manufacturing and Processing of MOST Components
16.1
16.1.116.1.2
16.1.316.2
16.2.116.2.216.2.316.2.4
16.3

249

Application of MOST150................................................................ 249
MOST150 technology evaluation................................................... 250
Requirements and evaluation structure ......................................... 250
MOST150 reference platform ........................................................ 252
MOST150_InCar ........................................................................... 252
Results of the technology evaluation ............................................. 253
Conclusion..................................................................................... 254
Outlook .......................................................................................... 255

MOST150 Migration
15.1
15.2
15.2.115.2.215.3
15.3.1
15.3.215.3.315.3.4239

Challenges in Testing MOST Systems .......................................... 239
Overview of the OEM Test Activities ............................................. 240
The Test Process .......................................................................... 241
Risk analysis.................................................................................. 241
Test design .................................................................................... 241
Test implementation ...................................................................... 242
Test evaluation .............................................................................. 242
Test management.......................................................................... 242
Component Tests .......................................................................... 242
Integration Tests............................................................................ 245
System Tests.................................................................................246
Test Tools...................................................................................... 247

Introduction of MOST150 in Series Production
14.1
14.2
14.2.114.2.214.2.314.2.4
14.3
14.4

17

267

Structure and Testing of Opto-Electronic MOST Components ...... 267
Header........................................................................................... 268
Set of Fibers .................................................................................. 270
Connectors .................................................................................... 275
Processing within the Scope of Electronics Manufacture .............. 276
Mounting and Soldering of Headers .............................................. 276
Mounting and Soldering of Connectors ......................................... 277
Mounting of Internal Sets of Fibers................................................ 278
Device Testing............................................................................... 278
Summary ....................................................................................... 279

18
17

Contents
Gateways to MOST
17.1
17.2
17.3
17.4
17.5
17.5.118

Distribution of Signals via a Gateway ............................................ 281
Architecture of a Gateway ............................................................. 282
MOST – CAN Gateway ................................................................. 283
MOST – Bluetooth Gateway .......................................................... 284
Routing of the Control Channel ..................................................... 285
Routing of the Synchronous Audio connections ............................ 286

MOST Applications
18.1
18.2
18.3
18.4
18.5
18.5.1
18.5.2
18.6

281

289

Overview ....................................................................................... 289
Infotainment Headunit ................................................................... 293
Media Interface Devices ................................................................ 295
Sound Systems ............................................................................. 296
Audio and Video Transmission Formats........................................ 298
Audio Streaming ............................................................................ 298
Video Streaming ............................................................................ 299
MOST for Driver Assist Applications.............................................. 301

Appendix

303

A

The Description Language Message Sequence Chart (MSC)305

B

Data rate of the Packet Data Channel of MOST25

310

C

Abbreviations

312

D

Glossary

318

E

Bibliography

325

Index

331

19

20

21

1
1.1

MOST Cooperation
Motivation and History

In the late 80s, when the first car networks for controlling devices and for carrying
multiple signals over one conductor were implemented, all car makers were still of
the opinion that such technologies had a high potential for differentiating theirproducts from those of other companies. Mercedes developed the CAN system,
while PSA (Peugeot Citroën) and Renault controlled their vehicle infrastructure via
VAN. As this was not suitable for the USA, J1850 was developed there. BMW, too,
had their own network, the I-Bus. It took some time for all parties to realize thatthese technologies all served the same purpose: to transmit bits and bytes between
devices. There is little differentiation potential in that. The different technologies,
however, meant a high expenditure of time and money for the car manufacturers.
They all developed similar but different functions and transmission technologies. It
took nearly twenty years until CAN became generally accepted. Nowadays, nearly
all vehicles across the globe control their interior functions and power transmissions
via various CAN networks. The efforts for developing the other networking technologies could have been spared, but in the 80s the time was not yet ripe for suchconclusions.
In 1996, the beginnings of MOST were being discussed at BMW, in collaboration
with Becker (today Harman Automotive Division) and OASIS Silicon Systems (today SMSC) – on the basis of the D2B system developed and put into production by
Mercedes – and it was decided to carry on this development together with other vehicle manufacturers. To develop individual solutions would have meant for thecompanies to individually bear all expenses again. The first contacts to Daimler
Benz were made, which were initially more of a cautious approach towards eachother than intensive collaboration.
Through a careful process, which was positively carried on by both car makers, theparties became closer and it was decided to collaborate on the development of
MOST. The initial phase was marked by the idea of only specifying and collaborating on network functions, such as the physical bus layer and the network management. The more intensive the collaboration and trust became, the easier it became to
discuss the application requirements which arose for the bus system. This joint
process, which the two car makers went through, was the foundation for the definition of the physical transmission layer and for the development of functional specifications. These specifications were later extended by compliance test specifications

22

1: MOST Cooperation

for the physical transmission layer, the network management (core compliance) andthe compliance on the application level (see chapter 12).
This initial collaboration resulted in the following fundamental agreement, whichcharacterizes the activities of the MOST Cooperation up to this day:
MOST was established to realize series developments. Instead of a theoretical standardization, there is collaboration on a practical basis, in order to specify and implement subjects which are required for use in series production. None of the parties
involved will obstruct the others. The party which handles the most timedemanding requirements for the individual functional components sets the pace.
Development requirements of those parties which cannot be realized within thistime frame will be dealt with in the next release.
After the first specifications had been drawn up together and the first steps of a joint
development had successfully been made, the idea came up to extend these activities. It was decided to found an open cooperation for the development and standardization of MOST. Other vehicle makers, device and component manufacturers
could join this cooperation on their own account without having to take regulative
hurdles.
In 1998 the MOST Cooperation was founded as a German civil law partnership(GbR) by BMW, Daimler Benz, Becker and OASIS Silicon Systems. Audi joined
the founding group soon thereafter.
When the MOST Cooperation became better known, the number of members
quickly increased to about 80. Nearly all vehicle manufactures around the worldand nearly all makers of infotainment devices and many components manufacturers
also joined.
The MOST Cooperation not only focuses on the technical development of MOST
and its respective specifications, but also on the promotion of the technology to become a global standard for multimedia networks in vehicles. In order to achieve
that, MOST Cooperation has engaged in commercial show events at exhibitions andcongresses throughout the USA, Europe and Asia. The MOST Cooperation has
been represented by its members on quite a number of exhibitions. At the ITSWorld Congress 2000 in Turin for instance, as a world premiere, several vehicle
makers presented with MOST a jointly developed technology. The vehicle manufacturers involved at that time (Audi, BMW, Mercedes and Volkswagen) joined thisevent with vehicles and the responsible designers.
Today there is a lot of cooperation between vehicle manufacturers. It has become amatter of course that infrastructural technologies, which are invisible for the customer, are jointly developed.

1.2 Fast Standardization

23

Fig. 1.1: Exhibition booth of the MOST Cooperation at the ITS World Congress 2000 withvehicles from Audi, BMW, Mercedes and Volkswagen

1.2

Fast Standardization

When the MOST Cooperation was founded, only the Network Interface Controller
OS8104 and a few specifications for the network management and the transportlayer were at hand. MOST had to get ready for series production deadlines. A faststandardization was therefore required, which is normally a contradiction in itself.
Standardization is usually associated with years of processing and endless discussions. How could a fast standardization be achieved?
In order to reach a broad standardization, a lot of companies have to contribute, but
discussions must be efficient. Decisions must be made quickly and therefore insmall groups. Only companies which are competent in a specific field should participate in the discussions. The operating mode of the Cooperation must be flexibly
adaptable to the requirements. Apart from that, there should be no irrelevant topics
on the agenda. The MOST Cooperation only works on projects which aim at becoming a standard in production vehicles. Each of the companies involved must accept and commit itself to the Cooperation’s philosophy (see section 1.1).

24

1: MOST Cooperation

The specific structure of the MOST Cooperation was defined in order to bridge thecontradiction between “fast” and standardization. It has proved reliable and hassince served as an example for a number of other cooperations,

1.3

Structure and Specification Work

Figure 1.2 shows the organizational structure, which is explained in detail hereunder.

1.3.1

The Steering Committee

The MOST Cooperation consists of the group of founders, who make up the Steering Committee, and of Associated Members, who are not members of the Steering
Committee. Only the members of the Steering Committee are partners of the MOST
Cooperation. They have the duty to cooperate, whereas the associated members cooperate on a voluntary basis. All members, however, may use the results of the
MOST Cooperation unrestrictedly and to the full extent. They grant each other freeright to use their respective contribution to the standardization.
The cooperation contract of the MOST Cooperation is only a rough cooperation
framework, which is brought to life by the Steering Committee. Within this framework, the Steering Committee defines how the standardization work should bedone, i.e., as the legislative branch it defines the rules of cooperation and can flexibly adapt them to a specific situation. The rules are described in the MOST Cooperation Organizational Procedures [MOST Org] document.
The Steering Committee, moreover, reserves the formal right to sign off all MOST
Cooperation specifications. It will use its right of veto only if absolutely necessary
and, as a rule, follows the recommendations of the technical groups with respect tothe specifications.
In addition to this, the Steering Committee takes care of the legal matters of the
MOST Cooperation, as well as of the cooperation with other industrial forums andof the MOST Cooperation’s promotion activities.
Apart from that, the Steering Committee is responsible for the MOST Cooperationbudget. This includes, besides budget planning and control of the operating results,
the statement of account for the members.

1.3 Structure and Specification Work

25

Fig. 1.2: Organization of the MOST Cooperation specification work

1.3.2

The Administrator

The Steering Committee appoints an administrator. He incorporates the decisions
made by the Steering Committee into the daily business of the MOST Cooperation.
He is also in charge of communication with the members or with applicants formembership. Additionally, he organizes the MOST Cooperation events and manages the website.

1.3.3

The Technical Coordination Group

The technical work of the MOST Cooperation is accomplished by the Technical
Coordination Group (TCG), which is made up of the Steering Committee members
and all other vehicle manufacturers. This ensures that the MOST Cooperation projects are implemented according to the requirements of the vehicle manufacturers
and are not just any random standardizations.
The TCG defines projects, establishes Working Groups (WG) and determines whoshould be coordinator of a WG. This is mostly an employee of that member company of the TCG for which the results of the project are most important. This ensures that the WG is managed and urged on by the member with the highest interestin the project. The TCG also invites other member companies to cooperate in the
new WG. This ensures that participants in a WG make useful contributions and that
the WG can work in a target-oriented manner. The number of participants is thus
also restricted to a reasonable number.
The TCG defines the aims of the WG and is regularly informed about the results. If
necessary, the targets are adjusted to new requirements. Should there be insoluble

26

1: MOST Cooperation

conflicts about targets, the WG can inform the TCG which can then make further
decision.

1.3.4

The Working Groups

A Working Group with a coordinator is put in place for each technical project of the
MOST Cooperation. The WG deals with the project according to the objectives set
up by the TCG. The organization of the work is up to the coordinator and the WG.
The WG only has to comply with the frame conditions as defined by the MOST Cooperation Organizational Procedures [MOST Org]. This ensures that the individual
groups can work according to their own philosophy and with their own means. Thisis necessary, as work on the physical bus layer for instance is subject to requirements different from work on the software level.
A WG usually creates one or several specifications. As soon as the WG has passed
a specification, it is checked for conformity with the specification rules by the central WG of the MOST Cooperation - WG Device Architecture. If no corrections arenecessary, the specification advances to the pre-release stage, where all members
can inspect and comment on it. If there is no need for correction here either, thespecification is released after eight weeks and becomes part of the official MOST
Specifications.

1.3.5

The Technical Coordinator

The MOST Cooperation also has a Technical Coordinator. He is a project manager
and controls the overall technical activities of the MOST Cooperation. He is thecontact person for the WGs, keeps an overview of their status and reports it to the
TCG. He coordinates processes, such as the release of specifications, which were
worked on by different WGs. The Technical Coordinator’s main task over all is toensure fast progress of the technical work.
Chapter 3 explains the structure of the MOST specifications.

1.4

The Compliance Verification Program

The MOST Cooperation aims at creating a standard, where all members profit fromsynergy effects, such as increased economies of scale for the key components. The
members thus grant each other the free right to use their intellectual property rights(copyrights, trademark rights, patents, etc.) which are necessary for implementing
the MOST specifications. All “owners” of MOST are interested in the1.4 The Compliance Verification Program

27

specifications only being used for MOST purposes and not being misused in partsfor other projects.
The process of Compliance Verification was defined in order to guarantee this aim.
Each device, for which the manufacturer obtains a license under the protective
rights of the members, must prove that it complies with the MOST specifications.
For this purpose, the MOST Cooperation specified MOST Compliance Tests, whichmust be passed by each device. Only if a device passes the tests, it is granted a license and can carry the MOST trademark.
Apart from the legal aspect of granting a license, the Compliance Tests are continuously extended to ensure interoperability between MOST devices and to check their
quality. It is not compulsory to use the MOST logo. If an implementer, however,
advertises with the MOST logo, it should stand for high quality and interoperability.
The procedure of Compliance Verification is described in chapter 12. It is generally
defined by committees within the MOST Cooperation, which are independent of thespecification groups. Some persons, however, may have dual functions in the
MOST Cooperation, which means they have one function in the specification organization and an additional function in the compliance groups.

28

29

2

Survey of the System ArchitectureThis chapter gives an overview of the system architecture and the basic characteristics of MOST, which are described in more detail in the following chapters.

2.1

MOST Layer Model

When the MOST system was developed, vehicle manufacturers had two basic demands with regard to the functionality of an infotainment bus system:
1. A simple system design based on a function-orientated point of view, and2. the transmission of streaming and packet data, as well as control information.
The first demand resulted in the development of the MOST framework with function blocks being the essential part. Function blocks incorporate all properties andmethods of a MOST device (e.g., a CD changer), which are necessary to control thedevice. Communication with these function blocks takes place over the application
protocol, which consists of a self-explanatory mnemonic and does not require an
address of the MOST device. Thus, a simple and fast system design of the infotainment domain is possible with a high abstraction level.
The function blocks constitute the interface with the application and therefore belong to layer 7 of the ISO/OSI model (fig. 2.1). They are introduced in section 2.2
together with the application protocol and explained in detail in chapter 3.
The second demand was achieved with the frame structure. It synchronously transports multimedia data, can transmit a great amount of data asynchronously without
influencing the synchronous transmission and offers a Control Channel for control
commands and status messages. The letter belongs to the application protocol.
The Data Link Layer is based, according to the above mentioned second demand,on a synchronous transmission of data frames. It is realized by the MOST Network
Interface Controller. Besides the more common optical bit transmission layer, there
is also an electrical physical layer available.
Section 2.4 gives a general survey of the Data Link Layer. This layer is presented inchapter 5. The Physical Layer is introduced in section 2.5. It is described in detail inchapter 6.

30

2: Survey of the System Architecture

Application
7

Presentation
6
Session5
Transport
4

Network Service
Basic Level

Network
3
Data Link
2

MOST Network Interface Controller

Physical
1Fig. 2.1: MOST in the ISO-OSI
model

The driver software of the MOST System, i.e., the Network Service, is a middleware between the function blocks and the Data Link Layer. It covers layer 3 up toparts of layer 7 of the ISO/OSI-Model. NetServices is the product name used by thecompany SMSC for the Network Service.
Due to the fact that the MOST system was developed for the synchronous transmission of audio and video data in particular, there are additional Stream Services used
for their transport. They are shown in figure 2.1, but do not belong to the actual OSI
model.

2.2

Application Framework

The key elements of the Application Framework are the above mentioned function
blocks and their dynamic behavior.
A function block is an object for controlling dedicated functions in the MOST network. There are function blocks for controlling applications, such as the CDchanger or audio amplifier, and function blocks for the network management. The
function blocks provide comprehensive tools for implementing complex audio functions. They make it relatively easy for the application design engineer to create distributed audio applications on a highly abstracted level.

2.2 Application Framework

31(e.g. AudioDiskPlayer)

FBlockProperty 1(e.g. TrackPosition (Displays the current or sets a new position as track))
Property 2(e.g. DeckStatus (Controls and shows the state of the drive
like Play, Stop, Pause))....
Property nMethod 1(e.g. Allocate (With this method the source will be caused to occupy
streaming connections))
Method m

Fig. 2.2: Function blockof the CD player (AudioDiskPlayer)

A function block defines the interface of an application to be controlled. It consistsof properties and methods. The properties describe or change the condition of thefunction to be controlled and the methods execute actions which, after a specified
period of time, achieve a result. The MOST specification uses the term “function”
to include both properties and methods.
In order to be able to ensure a uniform implementation, every function block has an
XML description used as an interchange format. This description can be edited with
the MOST Editor (section 11.2.2).
Figure 2.2. shows an example with extracts of the properties and methods of thefunction block of a CD player (AudioDiskPlayer).

HMI

Application

Controller
FBlockAudioDiskPlayer

Slave

FBlockAmplifierFig. 2.3: Hierarchy in the MOST system(according to [Tutorial])

The MOST specification differentiates between three views of the interaction withfunction blocks (fig. 2.3):


HMI



Controller



Slave

32

2: Survey of the System Architecture

A slave is a MOST device, which is controlled by a Controller. It provides its functionalities by means of properties and methods of its function blocks. A slave has nosystem knowledge at all, i.e., information about other devices is not stored staticallyand consequently the slave does not control other slaves either (fig. 2.4). They caneasily be added to or removed from a MOST system, without the software being
modified or other slaves being influenced. This means that a CD changer or amplifier, can easily be used in different vehicle platforms, if they are implemented asslaves

HMI
System Management
Application

Controller

Controller
FBlockFBlockFBlockFBlockController
Application

FBlockFBlockSlave

FBlockFBlockFBlockController
Application

FBlockFBlockSlave

FBlockFBlockFBlockSlave

FBlockFBlockFBlockFBlockSlave

Fig. 2.4: Interactions in the MOST hierarchy (according to [Tutorial])

A Controller is an application for administration of a functional part of a MOST
system, i.e., it controls the function blocks of one or more slaves (fig. 2.4). A tuner,
for example, can control its corresponding amplifier. For this purpose, the Controller requires partial system knowledge, which means that it must know the function
blocks to be controlled. A proxy (or stub) for a function block to which the Controller has access is also called the shadow of this function block. Apart from that, aController can also have function blocks of its own (see also section 4.1).
The Human Machine Interface (HMI) is the interface to the user of the MOST system and thus presents the system function on a high abstraction level. It coordinates
the various Controllers.
The Controller uses an application protocol, introduced in section 4.2 (see also fig.
2.5), to control a function block. It is transmitted via the Control Channel or the
MOST High Protocol in the Packet Data Channel. The device address of the addressed function block does not need to be known, as it is ascertained by the Network Service (see section 9.3.3).

2.3 New isochronous transmission mechanisms for MOST15033

CDC (Slave)

HMI (Controller)

Application
Application

CD.1.Track.Set(10)(Application Protocol)

FBlock CD
InstID: 1

Network Service

Network Service

Layer II

Layer II

Layer I

Layer I

MOST Network
InterfaceController

Device 1

HMI.CDC.CD.1.Track.Set(10)MOST Network
InterfaceController

Device 2

Fig. 2.5: Application protocol (according to [MOST3.0])

The description language Message Sequence Chart (MSC) is used for describing
the dynamic behavior and the use of the function blocks. MSC is a technical language which was defined by the International Telecommunications Union (ITU) for
specifying and describing the communication behavior of system components
among each other and with their surroundings. It is independent of the communication protocol used. The language is introduced in appendix A.

2.3

New isochronous transmission mechanisms for
MOST150

MOST150 can handle three different isochronous mechanisms designed for different applications.
The A/V Packetized Isochronous Streaming permits transfers of video data
streams that arrive without any reference to the MOST time base. The data is already consolidated in small data packets, which can optionally include a timestamp. MPEG data streams that are coded either with variable (VBR) or constant bit
rates (CBR) are typical examples of this.
DiscreteFrame Isochronous streams contain data and additional time base information in parallel. The data is arranged in frames. They are not synchronized to thetime base of MOST. All PCM streams fall into this category. Here, the PCM data is
accompanied by a frame sync signal. An example is the transport of a 44.1 kHz signal over a 48 kHz MOST network.
QoS IP (Streaming) mode is used for packet transmission which allows for full
quality of service requirements. Typically, resources on the Packet Data Channel

34

2: Survey of the System Architecture

are shared between all applications on the network. Certain scenarios require guaranteed bandwidth. For example, when transporting video data as an IP stream on
the MOST Ethernet channel, the occurrence of sudden, high-volume data transfer
would lower the available bandwidth for the video signal, affecting the video
transmission. If it uses QoS IP (Streaming) mechanism, the sudden data transfer
does not interfere with the video transmission, avoiding disturbances.

2.4

Network Services

Network Services are a standardized protocol stack for MOST, mapping level 3 up
to level 7 of the OSI model. They are usually divided into two layers. The Network
Services also include the transport protocol MOST High Protocol, the adaptation
layer MAMAC, which maps the TCP/IP stack onto MOST (only MOST25 andMOST50) and accordingly a pure TCP/IP stack for MOST150, so-called Ethernet
over MOST (see also chapter 5.7).
They are attached to the MOST Network Interface Controller and provide a programming interface for the application, which basically consists of the function
blocks (fig. 2.10). They contain modules for the transfer of packet data in the Packet
Data Channel and modules for the control of the network via the Control Channel.
The Network-Services are implemented on an External Host Controller (EHC). The
control of streaming connections is also part of the Network Services. However, thesynchronous/isochronous data transmission is not.

2.5

MOST Data Link Layer

The Data Link Layer defines the basic transmission mechanisms of the MOST bus.
This includes the definition of the structure of the data frames, as well as the function of the TimingMaster and the TimingSlave.

2.5.1

MOST Frame

The second requirement of the MOST system, i.e., the synchronous transmission ofmultimedia data, is directly reflected in the frame structure. A frame contains one
channel for the synchronous or isochronous (only MOST150) transmission of
streaming data, one channel for the asynchronous transmission of packet data, andone channel for the transmission of control data (fig. 2.6). In the Streaming Data
Channel, static connections between a streaming source and one or several streaming sinks can be built up with the sampling rates 44.1 kHz (MOST25 and MOST50)
and 48 kHz (MOST150).

2.5 MOST Data Link Layer

35

The control of the connection set-up and disconnection, and the exchange of thecontrol messages for the function blocks are effected via the Control Channel. The
data for the commands transmitted via the Control Channel are distributed over
several subsequent frames. A MOST25 frame provides two bytes in each frame forthat purpose, and both MOST50 and MOST150 frame contain four bytes.
Packet data is transmitted in the Packet Data Channel without influencing the synchronous data transmission at all. It transports configuration data of the navigation
system, for example. A data link layer protocol is used for that purpose, which covers the Packet Data Channel. It can transport pure Ethernet Data in MOST150.
The boundary between the Streaming and the Packet Data Channel can be set using
the boundary descriptor.
As figure 2.6 shows, a MOST25 frame contains 64 bytes in total. MOST50 cantransport 128 byte at the same time due to the double bandwidth, and MOST150
carries 384 bytes.
MOST25

Synch.

MOST50Synchronous

MOST150

Synch./ Isochronous

64 Bytes

Streaming Data Channel

128 Bytes+ 100Mbit/s Ethernet Channel

384 Bytes

Packet Data Channel

Control Channel

Fig. 2.6: Basic structure of a MOST frame

Chapter 5 gives a detailed introduction of the MOST protocols of the Data Link
Layer.

2.5.2

TimingMaster, TimingSlave

As MOST is a point to multi-point data flow system (i.e., the streaming data has asource and any desired number of sinks), all devices share a common system clock
pulse derived from the data stream. They are thus in phase with each other and cantransmit all data synchronously, which makes any mechanisms for signal bufferingand signal processing redundant.
The system clock is generated by the TimingMaster, which is integrated in one of
the nodes. In a vehicle, it is usually located in the head unit of the infotainment system. All other nodes are synchronized onto this system clock pulse by means of a
PLL connection and are thus referred to as TimingSlaves (fig. 2.7).

36

2: Survey of the System Architecture

When the TimingMaster receives the frame again when it has traveled around thering, it reclaims the signals by means of a PLL connection and subsequently generates the next frame.
Node A
TimingMaster
PLL

Generator

MOST Frame

Node D

Node B

TimingSlave

TimingSlave

PLL

PLL

PLL

Node C

Fig. 2.7: MOST ring with a TimingMasterand TimingSlaves

TimingSlave

Lock/Unlock
A TimingSlave is in a lock state if it receives a signal at the input onto which it cansynchronize with the PLL; if not, it goes into unlock state.
The TimingMaster is in lock state if it can regenerate the frame from the signal thathas traveled around the ring.
In the case of an optical Physical Layer, the lock state implies that the light is on in
the ring (Light On).
A more detailed description is given in section 7.5.1.

2.6

Physical Layer

Table 2.1 summarizes the most important parameters of the Physical Layer.
MOST25 stands for a bit rate of the data stream of about 25 Mbit/s and uses an optical Physical Layer. The exact data rate depends on the sampling rate of the system. At a sampling rate of 44.1 kHz, the MOST frame is transmitted 44,100 times
per second, which results in a data rate of 22.58 Mbit/s at a frame length of 512 bits
(see section 6.5.1). This also applies to MOST50. The frame here has a length of
1,024 bits, which results in twice the data rate at the same sampling rate. An electrical Physical Layer was additionally specified for MOST50.

2.6 Physical Layer

37

The first generation of the Network Interface Controllers (NIC) can only be used for
MOST25. The second generation Intelligent Network Interface Controllers (INICs)
are available for MOST25, MOST50 and MOST150. In chapter 10, both generations of MOST Network Interface Controllers are introduced.

MOST25

MOST50

MOST150

Bit rate

circa 25 Mbit/s

circa 50 Mbit/s

circa 150 Mbit/s

Physical Layer

OpticalElectrical
OpticalOS8104; OS8104A
OS81050; OS81060

OS81082; OS81092

NIC
INIC

Electrical (based on
coax line drivers)
OpticalOS81110; OS81120

Table 2.1: Important parameters of the Physical Layer

2.6.1

Optical Physical Layer

MOST uses Plastic Optical Fiber (POF) as physical transmission medium and has
therefore very good EMC properties.

Node A

Node D

Node B

Node C

Fig. 2.8: Simple MOST ring

The basic architecture of a MOST network is a logical ring, which transmits thedata from one device to another. The logical ring structure is usually realized as aphysical ring (fig. 2.8). This is, however, not mandatory. A combined ring and star
topology, for example, can be realized with one hub. In a star topology nodes can
simply be added or removed without the rest of the network being influenced,
which increases the system reliability.

38

2: Survey of the System Architecture

Node A

Node D

Node B

Node C

Fig. 2.9: Double ring struture

The principle of transmitting the data stream from one node to the next, which canbe arranged in a star topology or any possible mixed form of ring and star, is always
maintained.
In order to make MOST highly available in the case of errors, a double ring can berealized. For this purpose each node must have two optical receivers and two
transmitters (see fig. 2.9). If there is a problem between two nodes, the ring can beclosed via the redundant segments. The Bosch conference system Praesideo [Praesideo] uses such a double ring structure. It is employed in big complexes of buildings and complies with the European Safety Standard EN 60849.
The optical Physical Layer is introduced in detail in chapter 6.

2.6.2

Electrical Physical Layer

The electrical Physical Layers additionally specified for MOST50 and MOST150
based on coax line drivers are described in section 6.6.

2.7

MOST Device

The basic architecture of a MOST device, as it is shown in figure 2.10, can be deduced from figure 2.1. It shows a device with an optical Physical Layer (oPhy). The
Fiber Optic Receiver (FOR) transforms the light signal into an electrical signal,
which is transmitted to the Rx input of the Interface Controller. The Tx signal fromthe controller is retransformed into a light signal by the Fiber Optic Transmitter(FOX). Receiver and transmitter are called uniformly Fiber Optic Transceivers(FOT) or the physical interface.

2.8 Network Management

39

Audio Interface

External Host Controller (EHC)

Codec

Function
Block

Function
Block

Function
Block

NetBlockAppl.1

Appl. nNetwork Service
SP

CP

Low Level System Services

POF

Rx

Tx

FOR

POF
FOX

BypassFig. 2.10: MOST device
model with an optical Physical Layer

The Data Link Layer is realized in the MOST Network Interface Controller, which
controls the access to the three different channels. The Network Service and thefunction blocks are implemented on a microcontroller, which is also referred to as
External Host Controller (EHC). The access from the EHC to the Packet Data
Channel and the Control Channel is effected via the Control Port (CP) of the MOST
Network Interface Controller.
Chapter 9 introduces the Network Service.
For the streaming services, a processor-free codec can be used in the simplest caseor a signal processor in a high-grade system. The interface with the MOST Network
Interface Controller is the Source Port (SP) (in the case of the NIC) or the Streaming Port (in the case of the INIC). In addition to this, the INIC offers a universal, efficient interface through MediaLB, which can address all channels (see section
10.11).
The MOST Network Interface Controller has an integrated bypass. It is closed (activated) or remains closed, if the controller is not in normal operation mode, andthen transmits the incoming data stream nearly without delay and regeneration via
Tx. This applies, for example, in the case of errors or when the device is started up.

2.8

Network Management

In addition to function blocks for application functions (such as CD changer ortuner), there are also a number of function blocks for network management functions, such as the NetBlock, PowerMaster, NetworkMaster and the ConnectionMaster. They are introduced in chapter 7.

40

2: Survey of the System Architecture

The NetBlock must be implemented in every device. The other function blocks for
network management are found only once in the system. The specification does not
regulate, on which device these functions are implemented. They may be distributedin the system, but are usually found together in the head unit.

2.8.1

NetBlock

The NetBlock is responsible for the administration of a device. It has, for example, alist of all the function blocks implemented on the device, and manages all addressesof the device (node position address, logical address, group address). Section 4.3.4
goes into more detail.

2.8.2

PowerMaster

The PowerMaster defines the function of a selected device in the MOST network,
which is responsible for starting up and shutting down the MOST network and supervises the status of the power supply. It does not have a function block specification of its own, but a function block identifier for identifying the device. The function block PowerMaster is introduced in section 4.3.4.
The network can be woken up by any node. A wake-up which was not initiated by
the PowerMaster (e.g., by the gateway), is characterized as a slave wake-up.
Node A
Network
MasterCentralRegistry
Network
Slave

Network
Slave

Decentral
Registry

Decentral
Registry

Node
B

Network
Slave
Decentral
Registry

Node C

2.8.3

Fig. 2.11: NetworkMaster andNetworkSlave

NetworkMaster; NetworkSlave

The NetworkMaster starts up the system and administers the network status, as wellas the Central Registry. The latter lists all function blocks existing in the network,2.9 Error Management and Diagnosis

41

and the respective address of each device, on which a function block is implemented.
All other devices in the ring are called NetworkSlaves. They may have a Decentralized Registry, a subset of the Central Registry. It comprises the function blocks ofthe communication partners of the device.
Figure 2.11 shows a MOST ring with the NetworkMaster and the Slaves.
The NetworkMaster function is the central part of chapter 7.
The respective function block is the NetworkMaster (section 4.3.4).

2.8.4

ConnectionMaster

The ConnectionMaster is the function block that contains the interface to the Connection Manager, which is responsible for set-up and disconnection of streaming
connections. The implementation of the ConnectionMaster function block is optional (see also chapter 4.3.4).
Figure 2.12 shows the basic operational mode of the ConnectionMaster. An initiatororders the ConnectionMaster to establish a connection. Thereupon it reserves thenecessary bandwidth in the synchronous area and reports the channel number of thedata source and sink. The disconnection is carried out analogously.
Initator

Connection
MasterAudio Source Synchronous Channel
Device

2.9

Audio Sink
DeviceFig. 2.12: Basic principle of theConnectionMaster

Error Management and Diagnosis

MOST specifies a ring break diagnosis. It can locate broken POFs and delivers theresult to a dedicated device. It includes also an optional Electrical Line Control.
Chapter 8 goes into more detail.
The Diagnostic Protocols Adaption Specification [DPA] defines requirements forthe adaption of diagnostic protocols, e.g., UDS (Unified Diagnostic Services) to
MOST.

42
2.10

2: Survey of the System Architecture

Transmission of Multimedia Data

For transmitting content through streaming connections, coding procedures have tobe defined and the copy protection is to be ensured, particularly for commercial entertainment content, protected by some form of access method.
MOST uses current coding procedures, such as PCM and MPEG, the implementations of which are to be found in the MOST Specification for Stream Transmission[Stream].
MOST applies the Digital Transmission Content Protection (DTCP) standard fortransmitting content protected by copyright. This technology comes from the 5C
Group, a cooperation of the five device manufacturers Intel, Matsushita, Toshiba,
Sony and Hitachi. It is available on the website of Digital Transmission Licensing
Administrator (DTLA) www.dtcp.com. DTCP was developed to ensure the safe
transmission of signals from a set-top box to the DVD video recorder. The renowned Hollywood studios Sony and Warner also use this protection scheme in order to transport films in digital networks.
The MOST specification MOST Content Protection Scheme DTCP Implementation[ContProt] defines the necessary functions and services to enable the use of thistechnology.

43

3

Survey of the MOST Specifications

This chapter gives a survey of the structure and composition of the MOST Specifications. The current status of the specifications in the amended version can be gathered from the updated list of documents of the MOST Cooperation website(http://www.mostcooperation.com).

3.1

Structure

Figure 3.1 reflects the structure of the MOST Framework and illustrates the dependencies of the documents. The MOST Specification is the main document
within the MOST Framework. The arrows thus point to the MOST Specification as
reference for all other documents, such as the specifications of the MOST function
blocks (FBlocks) and the corresponding dynamic specification.

MOST Framework

MOST Specification

MOST FBLOCK APIs
MOST FBLOCK APIs

MOST Dynamic Specification

MOST Physical Layer
Specification

MOST Electrical
Physical Layer
MOST Optical PhysicalSpecification
Layer Specification
MOST AOPhysical

MOST Stream
Transmission Specification

MOST HighSpecification

MOST Content Protection

Layer Specification

MOST Guidelines:
MOST MSC Cookbook
MOST FBlock Cookbook

Other documents

Fig. 3.1: Structure of MOST documents

MOST Compliance Test Specifications
MOST Guidelines:
MOST DTCP Test Recommendations

44

3: Survey of the MOST Specifications

3.2

MOST Specification

The structure of the MOST Specification [MOST 3.0] follows the layer model andbasically comprises the following sections:

Application



System concept of MOST

Device modelCommunication between MOST devices



Function classes



Network

Data transportControl Channel

Packet Data Channel

Synchronous ChannelIsochronous Channel

Ethernet Channel

Dynamic device behavior



Error management

Diagnosis

The MOST System uses a function model which allows a high abstraction of thephysical network. The communication uses function blocks (FBlocks) and functions
which can exist in the physical network detached from the physical devices.
Based on the function model, the MOST System has a strict hierarchic structure.
The uppermost level is the System Master, with one or more Controllers controllinga number of Slaves. This hierarchic structure concentrates the system knowledge
within only a few components: in the System Master and the Controllers.
The System Master, which is usually located in the Human Machine Interface(HMI), controls the overall system on a high abstraction level and provides the user
with the system functionality.
A Controller has partial system knowledge. It controls complex functional system
extensions and makes them available to the superior level in a simplified form.
Every Controller is an “expert” for the handling of specific functionalities, such as
all audio functions.
After the introduction of the system concept, the MOST Specification deals with thecommunication between MOST devices and the function classes.

3.2 MOST Specification

45

In the section about the Network, the structure of the MOST telegram and the different data transport concepts (Control Channel, Packet Data, Synchronous,
Isochronous and Ethernet Channel) are introduced.
The section about the Dynamic Device Behavior explains the system states, the system start-up and the registration of the function blocks in the NetworkMaster. Additional topics are the system wake-up, error management and the diagnosis.
Startup
msc NM_Sc_Scan_ConfigStatus_To_Ok
NetworkMasterpage 1 of 1

NetworkSlave_1

NetworkSlave_2

NetworkSlave_N

parFBlockIDs.Get
FBlockIDs.Status(FBlockIDList=_)Update the Central
Registry

1

2

FBlockIDs.Get
FBlockIDs.Status(FBlockIDList=_)Update the Central
Registry
FBlockIDs.Get
FBlockIDs.Status(FBlockIDList=_)Update the Central
Registry
All nodes have registeredwithout errors.
opt
when SystemState NotOk
B Configuration.Status
Configuration.Status
Configuration.Status(ConfigurationControl='Ok') (ConfigurationControl='Ok') (ConfigurationControl='Ok')

Revision: 1.6

Date: 2004/12/15 13:22:24

Configuration.Status(ConfigurationControl='Ok')

NetworkMaster.mpr,vFig. 3.2: Exemplary scenario: Regular System Scan

The section Error Management describes the behavior in the case of undervoltage,excess temperature and device error and additionally describes system errors, suchas the loss of synchronism (Unlock) and the change of registration (Network
Change Event) (see section 7.1.2).
The section Diagnosis comprises the ring break diagnosis, the Sudden Signal Off
behavior as well as the coding error counter. Through these, feature specific automotive requirements are met.

46
3.3

3: Survey of the MOST Specifications

MOST Dynamic Specification

The MOST Dynamic Specification [DynSpec] is closely connected with the MOST
Specification. It takes up the subjects of Network Management, Connection Management and Power Management from the MOST Specification and describes themin the form of Message Sequence Charts (MSCs).
Figure 3.2 shows the example of the scenario Regular System Scan with the communication partners NetworkMaster and NetworkSlaves. In the par section the NetworkMaster queries, by means of the Control Message FBlockIDs.Get(), all
MOST devices about the operable function blocks. It thus builds up the Central
Registry. The opt section describes the case that the NetworkMaster sends the Control Message Configuration.Status(OK), if the network is in the NotOK state(see section 7.1.2).

3.4

MOST Function Catalog

In the MOST function catalog (FBlock Library) all defined function blocks are described. Table 4.7 (section 4.4.1) already gives a survey of the available function
blocks.
Every FBlock has its own document, specifying the static and dynamic behavior of
the FBlock. The static information structures are described by means of XML. Its
structure is defined in a function catalog DTD (Document Type Definition), and isreferenced in the DTD Cookbook [DTD Cook]. The dynamic behavior is describedin the form of scenarios by means of Message Sequence Charts in accordance withthe dynamic specification [DynSpec] (see section 3.2).
Figure 3.3 gives a survey of the static description mode of the function NotificationMatrixSize of the FBlock EnhancedTestability. By means of this function, theminimum and maximum values of the size of the Notification Matrix across all
FBlocks of a device are given. This function is mandatory, i.e., it must always be
implemented. It uses the OpTypes Get, Status and Error. The parameters MinSize
and MaxSize, used by Status, are of the data type Unsigned Byte.

3.5

MOST Compliance Test Specifications

According to the structure of the certification test process (chapter 12), the individual scopes are provided with the respective test specifications.
The document MOST Compliance Requirements [ComReq] illustrates the general
workflow of the certification test process.

3.5 MOST Compliance Test Specifications

47

The optical Physical Layer Tests are described in the documents MOST Compliance
Test of Physical Layer [ComPhyL 1.0 ] and MOST Compliance Verification
Procedure – Physical Layer [ComPhyLP 1.0] for MOST25 as well as MOST150
oPhy Measurement Guideline [ComPhyL 150] and MOST150 oPhy Compliance
Verification Procedure – Physical Layer [ComPhyLP 150]. Possible corrections oramendments are laid down in the respective Errata Sheets ([ComPhyL_Err] and[ComPhyLP_Err]). The tests for the electrical physical layer are specified in the
document MOST ePhy Compliance Test Specification (with ePhy Compliance Test
Patterns) [Com_ePhyL].

Fig. 3.3: Example of the static description from the FBlock EnhancedTestability [FBET]The test cases of the Core Compliance scope are specified in the document MOSTCore Compliance Test Specification [Core] and the errata in [Core_Err].

48

3: Survey of the MOST Specifications

The document MOST Profile Compliance Test Specification [ComProf] describes
the generic tests of the Profile Compliance scope.
The tests for the individual function blocks and APIs are dealt with in test specifications of their own, for example in the MOST Profile ConnectionMaster Compliance
Test Specification for the ConnectionMaster.

3.6

Further Specifications, Guidelines and Cookbooks

The following items also belong to to the specifications of the MOST Framework:


The Physical Layer Specification



The MOST High Protocol, defining the transmission of Application Messages
via the Packet Data Channel [MHP]The MAMAC (MOST Asynchronous Medium Access Control) Specification
for transmitting network protocols, such as TCP/IP, IPX, NetBEUI and ARP[MAMAC]The MOST Content Protection Specification



The MOST Stream Transmission Specification, defining the streaming formats
for transmission of audio-visual dataApplication Recommendations (e.g. [MOST 2003])



Guidelines and Cookbooks

Apart from the specifications, it is important to document the collected know-how
and procedural methods in an adequate manner. On the one hand, this is accopmplished by Application recommendations which provide, e.g., best practicetest procedures by the System Integrators. On the other hand, this is accomplishedby means of Guidelines and Cookbooks, e.g., the MSC-Cookbook [MSC] (see appendix A) regarding the use of Message Sequence Charts, the DTD-/XMLCookbook [DTD Cook] and the FIBEX Cookbook [FBX Cook]. They are a collected wealth of experience and focus the wide stream of possible descriptions to
the essential aspects.

49

4Application Framework

The MOST Specification defines not only the lower layers of a MOST network,
which provide the basics for the transmission of data and for the network management, but also the protocols and mechanisms for implementing applications on topof those. In the MOST Specification the interface of an application is called a function block (FBlock) and can be compared to a profile of the Bluetooth standard (see[Bluetooth]).
The MOST Application Framework permits the creation of applications that are independent of a specific implementation on a certain device and of those of the otherapplications with which they interact in a MOST system. When using the standardized FBlocks of the MOST Specification re-usable and interoperable applications
can be developed. An application, for example, that implements the Human Machine Interface (HMI) for a radio can thus be used with any device which offers thestandardized application interface of a radio tuner. Devices of different manufacturers can also be used together, if they implement compatible interfaces.
This chapter describes the aspects of the MOST Specification that define the MOST
Application Framework, starting with the description of the device model it is basedon. The protocol that applications use to exchange data in a MOST system is described next. Finally, the interfaces necessary for the administrative tasks in a
MOST system as well as the interfaces for typical applications in vehicle infotainment systems and examples for their usage are given.

4.1

Device Model

Figure 4.1 shows the model of a MOST device as defined in the MOST Specification. On the hardware level, a device has access to the physical transmission layer
via the MOST Network Interface Controller (NIC). The Network Service implements a driver layer that controls the access to the interface controller chip and enables applications to carry out basic functions such as sending and receiving messages.
In the MOST Specification, the interface of an application, which offers a specificfunctionality (i.e., in this context a group of related functions), is referred to as an
FBlock. Each device must implement the FBlock NetBlock, which is required foradministrative tasks within the MOST system (see section 4.3.3), and the FBlock
EnhancedTestability due to compliance reasons. Additionally, each device can,according to its type, implement one or more FBlocks for the functionalities of50

4: Application Framework

corresponding applications. For example, it is quite possible that a device offers thefunctionality of an amplifier, as well as that of a radio tuner, which are then each
represented by a corresponding FBlock in the system.

Function
Block

Function
Block

Function
Block

NetBlock

Application 1

Application 2

Network Service

MOST Network Interface Controller

Physical Layer

MOST Device

Fig. 4.1: Model of a MOST device

An FBlock is addressed within a MOST system through its functional address. This
ensures that its functionality can be accessed irrespective of the physical location of
its functions (i,e., it is not important on which device the functions represented by
the FBlock are implemented).
An FBlock, whose functions are used and controlled by an application, is referred toas a Slave. An instance, such as an application, which uses the FBlock, is referred toas its Controller (see fig. 4.2).

Slave

Controller
Application

FBlockNotification of changes
Call of methods

Properties...
...
Methods...

MOST Device

Functions

Setting/Reading of properties

MOST Device

Fig. 4.2: Interacting with an FBlock

Within an FBlock, a differentiation is made between two types of functions. One
type is a property that describes a specific attribute of the FBlock (e.g., the currently

4.2 Application Protocol

51

tuned frequency of a radio tuner), the other a method that triggers a certain action(e.g., a scan for the available radio stations).
A Controller can read the values of the properties of a Slave and, if the respective
properties support this, modify them. Additionally, the MOST Specification defines
a notification mechanism, by which the Controller registers its interest in particularproperties of the Slave and is subsequently informed by the Slave about any
changes.
Methods are called by the Controller to trigger a corresponding action of the Slave.
After performing the method, the Slave returns the results of the execution to theController.

4.2

Application Protocol

As a central aspect of the MOST Application Framework, the MOST Specification
defines a communication protocol for the interaction between applications in a
MOST system. This application protocol is based and depends on the protocols of
the underlying channels. In the early MOST systems, it was typically used with the
MOST Control Channel. Because of the increasing size of the transmitted content,
currently the Packet Data Channel is also used more frequently.
On the Control Channel, the protocol for sending application messages is called
Application Message Service (AMS). On the Packet Data Channel, application
messages can be sent using the MOST High Protocol (MHP). These protocols,
which handle, for example, segmentation and flow control, are described in detail inchapter 5.
The MOST application protocol determines how to access the services offered by
an application in a MOST system. It describes the data format for the messages,
which are exchanged for that purpose. It further describes the operational sequences
and conditions for read and write access to properties and methods of an FBlock, aswell as the use of the notification mechanism.

4.2.1

Data Format

This chapter illustrates the data format of the Application Message Service (AMS)
protocol. It consists of the following elements:[DeviceID.]FBlockID.InstID.FktID.OPType (Data)
When describing communication sequences or examples the above notation is used,
in which the individual elements are separated by a dot.

52

4: Application Framework

Basically, the data format contains the following three areas:
3. The addressing area consisting of an optional device address (DeviceID), theidentifier of the FBlock (FBlockID), and its instance (InstID) in the MOST system.
4. The addressed function with its function identifier (FktID), as well as the operation to be applied to the function (OPType).
5. A data field consisting of a length indication (Length) and the data area for theparameters of the function (Data).
The following table shows an overview of the individual elements and their respective size.

Element

Size

Description

DeviceID 1
FBlockID
InstIDFktID
OPTypeLength 2Data

16 bits
8 bits8 bits
12 bits
4 bits
16 bits
0 to 65535 bytes

Target device address
FBlock identifier
Instance of the FBlock
Function identifier
Operation
Length of data field
Data field

Table 4.1: Elements of the MOST Application Protocol

Device Address (DeviceID)
The device address (DeviceID) has a size of 16 bits and describes, depending on thecontext, the receiver, a group of receivers, or the sender of a message.
When addressing individual devices on application level the logical device address
is used. Addressing with the node position address is used only for network management or debugging. By using a group address several devices of a MOST system can be addressed simultaneously. The broadcast addresses 0x03C8 (blocking)and 0x03FF (unblocking) are used to address all devices in a MOST system. The
device address and the different modes of addressing will be described in detail inchapter 5 MOST Protocols.

1

The DeviceID is not used in the higher layers of the MOST Network Service(Layer II), since FBlocks are only addressed via their functional address.

2

The length is not transmitted directly, but is based on the underlying protocol.

4.2 Application Protocol

53

When programming on application level, the device address is often not used. Addressing can take place here using only the functional address (FBlockID and InstID). If an application does not know the network address of its communication
partner (which is usually the case), it can insert the wildcard 0xFFFF for reference
into a message to be sent and pass the message on to the Network Service. The
Network Service determines the address of the communication partner and replaces
the wildcard with it before sending the message (see section 9.2.3).
FBlock Identifier (FBlockID)
The FBlockID describes the type of FBlock and has a size of 8 bits. The FBlockIDs
below 0xA0 are defined by the MOST Specification, with specific FBlockIDs reserved for FBlocks required for administrative tasks, which are called system
FBlocks, or characterizing specific device functions or device types (see table 4.2).
Sections 4.3 and 4.4 of this chapter deal with the system FBlocks and application
FBlocks standardized by the MOST Cooperation.
In other areas, the system integrator (FBlockIDs from 0xA0 to 0xEF without 0xC8)
or the manufacturer of the device (FBlockIDs from 0xF0 to 0xFE without 0xFC)
can define proprietary FBlocks. The FBlockID 0xFF is used as a wildcard, in orderto address all FBlocks in a device except for the NetBlock.

FBlock nameor area

FBlockID(s)Description

Reserved
NetBlock

0x00
0x01

NetworkMaster

0x02

ConnectionMaster0x03

PowerMaster
EnhancedTestability
Reserved

0x04

Reserved for use by the Network Service
System FBlock, implemented by each device
System FBlock for the NetworkMaster, implemented by one device in the system
System FBlock for the ConnectionMaster, optionally implemented by one device in the system
Indicates the PowerMaster in the system

0x0F

Implemented by each device

0x70 to 0x9F

System specific

0xA0 to 0xEF

Supplier specificReserved
Supplier specificWildcard, All

0xF0 to 0xFB
0xFC
0xFD, 0xFE
0xFF

Reserved for future use
Assigned by the System Integrator (0xC8 isreserved)
Assigned by the device manufacturer

Table 4.2: Structure of the FBlockID area

Assigned by the device manufacturer
FBlock broadcast

54

4: Application Framework

Instances of FBlocks (InstID)
Since several FBlocks of a certain type may be used in a MOST system, such as anintegrated CD drive in addition to an external CD changer, a further differentiation
is made between their respective instances via the InstID. The InstID has a size of 8
bits; its default value is 0x01. FBlockID and InstID together are called the functional address of an FBlock.
The combination of FBlockID and InstID must be unambiguous throughout a system. For its own FBlocks, a device itself is responsible for the suitable allocation of
the InstIDs, for example by putting them into ascending numerical order startingwith 0x01. The NetworkMaster is responsible for the functional addresses being
unambiguous throughout the system (see section 4.3.4). For example, two different
physical devices implement a CD player with the FBlock AudioDiskPlayer andeach initializes the InstID with 0x01. This means that the functional address
0x31.0x01 would exist twice in the MOST system. In the case of such a conflict,
the NetworkMaster must reset an InstID. As an alternative to the dynamic handlingof InstIDs, they can be preset statically by the System Integrator.
The InstID values 0x00 and 0xFF have a special function as wildcards, in case a
device implements several FBlocks of a specific type. 0x00 addresses any instanceof the corresponding FBlock on a given device (don´t care). 0xFF addresses all instances on the device (broadcast). Wildcards can only be used in requests. The response messages must include the correct InstID of the answering FBlock.
For the case of system FBlocks, the MOST Specification requires a special handlingof InstIDs. For those FBlocks that must be implemented by every device (i.e., NetBlock and EnhancedTestability), the InstID corresponds to the ring position. Starting with 0x00 for the TimingMaster, it is increased by one for each device according to its position in the ring.
The FBlock NetworkMaster, where only one instance is allowed in the system, defaults to InstID 0x01; the InstID 0x00 is also allowed. In the case of requests, thewildcard 0x00 must be used.
Function Identifier (FktID)
Individual functions of an FBlock are distinguished from one another through the
FktID, which has a size of 12 bits. A function can either be a property (i.e., a variable of the FBlock) or a method. Whether a function is a property or a method,which operations it supports, and which parameters are used (see the following sections), is defined by its interface description in the FBlock specification.
The differentiation between properties and methods is discussed in detail in section
4.2.2, which also deals with the use of the respective function types and their usage.

4.2 Application Protocol

55

In the case of the FktIDs, the following subareas are differentiated (see table 4.3).
Functions from the “Coordination” area (FktIDs 0x000 to 0x1FF) must be implemented by all MOST devices in the same manner. This area is coordinated by the
MOST Cooperation via the GeneralFBlock specification (see section 4.4.2). The“Application” area (FktIDs 0x200 to 0x9FF) defines functions that represent themain application for a specific FBlock according to its FBlock specification. The
unique area (0xA00 to 0xBFF) contains functions, which may only exist once in a
MOST system. In this case, the System Integrator has to take care to coordinate theusage throughout the whole system.
Similar to the FBlockIDs, the System Integrator (FktIDs 0xC00 to 0xEFF) or thedevice manufacturer (FktIDs 0xF00 to 0xFFE) can specify proprietary functions.

Name
Coordination
Application
UniqueSystemspecific
Supplier
specific

FktID
area
0x000 to0x1FF0x200 to
0x9FF
0xA00 to
0xBFF
0xC00 to
0xEFF
0xF00 to
0xFFE

Description
Functions for administrative purposes in an FBlock thatare coordinated by the MOST Cooperation
Functions that represent the main application functionality of the FBlock
Functions that are defined unambiguously in the entire
systemFunctions that can be used by a System Integrator
Functions that can be used by a device manufacturer

Table 4.3: Structure of the FktID area

Operation Type (OPType)
Depending on the type of function (property or method) different basic operations
can be applied to a function. Operations are the basic elements of the interaction
patterns for properties and methods that or defined by the application protocol. An
operation is specified by the OPType, which has a size of 4 bits.
The following table shows the total of 16 individual operations. They have different
meanings, depending on the function being a property or a method of the FBlock.
The first nine operations describe a request to the function and are thus used in messages that are sent by a Controller to a Slave. The last seven operations describe theanswers of the Slave and are used in the corresponding reports.

56

4: Application Framework

OPType of Properties OPType of Methods
Requests:

Responses:

Set
Get
SetGetIncrement
Decrement
GetInterface ErrorAck 
Reserved
StatusInterface2
Error

OPTypeStart (deprecated)1
0x0
Abort (deprecated)1
0x1
StartResult (deprecated)1 0x2
Reserved
0x3
Reserved
0x4
GetInterface2
0x5
StartResultAck
0x6
AbortAck
0x7
StartAck
0x8
ErrorAck 0x9
ProcessingAck
0xA
Processing (deprecated)1 0xB
Result (deprecated)1
0xC
ResultAck
0xD
2
Interface
0xE
Error 0xF

Table 4.4: Operation types

The meaning of the different OPTypes and their use in the operational sequences
will be explained in section 4.2.2.
Size of the Data Area (Length)
The element Length indicates the size of the data area in bytes and has a size of 16
bits. Therefore, a maximum of 65,535 data bytes is possible, with the length 0 designating an empty data field.
The element Length is not transmitted directly, but is calculated by the Network
Service using the information of the underlying protocol layer depending on the
protocol (e.g., AMS or MOST High Protocol). For example, when the AMS is used,

Since MOST Specification 3.0 all OPTypes for methods without a SenderHandle
parameter are deprecated.



The OPTypes Interface and GetInterface are optional.

The OPType ErrorAck may be returned by a property if by mistake an AckOPType has been used in a request.

The OPType Error may be returned by a method, if the SenderHandle is not applicable or unknown.

4.2 Application Protocol

57

the length is calculated from the number and the length of the individual telegramson the Control Channel.
Data and Parameter Types
If a function has one or more parameters, the corresponding parameter values aretransmitted in the data field Data. The types and sequence of the parameters arepredetermined by the specification of the function’s interface in the FBlock specification.
The MOST Specification defines the parameter types indicated in the following
table:

Parameter

Size

Description

Boolean
BitField
Enum
Unsigned Byte
Signed Byte
Unsigned Word
Signed Word
Unsigned Long
Signed Long

1 byte1, 2, 4, or 8 bytes
1 byte1 byte1 byte2 bytes
2 bytes
4 bytes
4 bytes

StringVariable

StreamClassified
StreamVariable

Boolean value (true or false)
Bit field with Mask
Enumeration
Integer value (without sign)
Signed integer value
Integer value (without sign)
Signed integer value
Integer value (without sign)
Signed integer value
Null terminated string with encoding information
A stream of arbitrary data

VariableA stream with type information

Variable(up to 255 bytes)

Short stream with length information

Short Stream

Table 4.5: Parameter types of the MOST application protocol

The individual parameter types are summarized below. For a more detailed description please see the MOST Specification [MOST 3.0]. The characteristics of the individual parameter types are similar to parameters used in other programming languages.


Boolean: A parameter of type Boolean can have one of the values True orFalse. Only the lowest-value bit of the respective byte is used.



BitField: The parameter type BitField specifies a bit sequence that can have a
total size of 1, 2, 4 or 8 bytes, as required. According to the MOST Specification the first half of a parameter of type BitField is a mask and the second half
its data. When performing an operation, the bits of the mask indicate on which

58

4: Application Frameworkof the corresponding bits of the data the operation is to be applied. In practice,
this parameter type is sometimes also used without a mask.



Enum: A parameter of type Enum can adopt one of a maximum of 256 possible pre-defined values. The individual values and their meanings are determined by the function’s interface definition.



Signed/Unsigned Byte, Signed/Unsigned Word, Signed/Unsigned Long (integer values): The MOST Specification supports the indicated integer values
with a size of 1, 2, or 4 bytes, each with and without sign. For numerical values
with signs, the sign is determined by the most significant bit and the value iscoded in two’s-complement. (The MOST Specification up to version 3.0 does
not provide special parameter types for floating-point numbers. Instead, thedecimal place for the number parameters can be defined by indicating an exponent value in the interface definition.)String: For the transmission of character strings, the parameter type String isused. The first byte of the string indicates its coding, e.g. 0x00 for UTF16 and0x01 for ASCII. It is followed by a null-terminated character string, in which 1,
2 or more bytes are used for each character depending on the coding. The endof the character string is characterized by a null byte; two null bytes in the caseof codings with two characters (such as UTF16).

Stream: The parameter Stream defines an arbitrary byte sequence and is used if
no suitable description by the other parameter types is possible or if a dynamic
data structure is required. If the parameter type Stream is intended to be used
together with other parameters, only one of the parameters may be a Stream
and it has to be the last parameter.



Short Stream: The Short Stream is intended for representing a short byte sequence. It has a maximum length of 256 characters, with the first character indicating the length of the subsequent byte sequence (255 bytes at most). Because of the length information it does not have the same restrictions as the parameter Stream and can be used anywhere in the sequence of a function’s parameters.

Classified Stream: In the case of the Classified Stream, the first two bytes indicate the length of the stream and a subsequent null-terminated ASCII string(without coding information) indicates the media type. The media type corresponds to the ones in the HTTP1.1 specification (see [RFC 2616]).

To handle more flexible data structures, the concept of stream cases and stream
signals has been introduced. Both are defined in the function’s interface definition.

4.2 Application Protocol

59

With stream cases and stream signals, a parameter of type stream can be structured
in two different ways:
With stream cases a parameter of type stream is further structured into different
sequences of stream parameters depending on the value of a selector, similar tothe concept of a variant record in programming languages. The selector is a parameter of any type that has to occur before the stream. Often, parameters oftype Enum are used as selectors. Depending on certain predefined values of theselector, the stream will consist of a sequence of stream parameters with different types and numbers.

With stream signals, a stream is divided into different consecutive named elements, each with an arbitrary number of bits.

For details on stream cases and stream signals see the MOST Specification [MOST
3.0].

4.2.2

Dynamic Behavior

After describing the message format of the MOST application protocol and its individual elements, this section deals with its use and the resulting message sequences.

Controller

Slave

FBlock.Inst.Function.Get
alt
FBlock.Inst.Function.Status(Data='Parameter Values')

FBlock.Inst.Function.Error(Data='ErrorCode, ErrorInfo')

Fig.4.3: Querying the values of a property with the operation Get

Querying and Setting of Properties
As already explained, a function is either a property or a method. A property describes a specific variable of an FBlock and consists of one or more parameter values. The values of all properties of an FBlock indicate its current status. The valuesof a property can be queried or set via the MOST application protocol. In addition
to that, the MOST Specification specifies a notification mechanism by means of

60

4: Application Framework

which a device, which is interested in the value of a specific property, is automatically informed of its changes.
To query the current status of a property, a control message with the operation Get(OPType: 0x1) is sent to the corresponding function of the FBlock. If no error occurs, the latter answers with a message containing the operation type Status (OPType: 0xC) and the current value of the property in the data field. Otherwise, an error message of the operation type Error (0xF) is sent back (see the following section
on error handling).
Figure 4.3 shows the corresponding sequence as a Message Sequence Chart (MSC)in MSC 2000 notation [Z.120 99]. This notation is used by the MOST Cooperation
and we will also use it for describing the following examples. For a description of
the use of MSCs within the MOST Specification, see appendix A and [MSC].

Controller

Slave

FBlock.Inst.Function.Set(Data='Parameter Values')
opt
FBlock.Inst.Function.Error(Data='ErrorCode, ErrorInfo')

Fig.4.4: Setting the value of a property with the operation Set

The operation Set (OPType: 0x0) is used when no feedback is necessary after thevalue of a property is set (see fig. 4.4). Only if an error occurs during the process
does the FBlock answer with the corresponding error information. The operation
Set should be used when the Controller has set a notification for the corresponding
property (see the following section concerning the notification mechanism).

4.2 Application Protocol

Controller

61

Slave

FBlock.Inst.Function.SetGet(Data='Parameter Values')
alt
FBlock.Inst.Function.Status(Data='Parameter Values')

FBlock.Inst.Function.Error(Data='ErrorCode, ErrorInfo')

Fig.4.5: Setting the value of a property with the operation SetGet

The SetGet operation (OPType: 0x2) is similar to Set, with the difference that astatus message with the resulting new value of the property is sent back as confirmation that the change was carried out (see fig. 4.5). This way of accessing properties is to be preferred when a notification for the property is not used at the same
time.
Additionally, the MOST Specification defines the operations Increment (OPType:0x3) and Decrement (OPType: 0x4), by means of which the value of a property canbe increased or decreased by an amount specified in its interface specification.
These operations, however, are less commonly used compared to the other ones
previously described. Also, they are more prone to errors, as an unintentional retry
increases or decreases the value by two steps instead of one.
Executing Methods
Methods can be used to start a process that changes the status of an FBlock, or
represents a long-lasting process (e.g., starting the station scan in the case of a radio
receiver).
A Controller can start and, if necessary, abort methods. When starting the method, asequence of parameters is optionally added which influences the behavior of themethod (such as the direction of the station scan). The results which are possibly
generated by the method (in this case, for example, the list of the stations) are thenreturned to the initiator.
In order to differentiate between Controllers within a device (e.g., different applications) that have started a given method, all operations for methods additionally include a special parameter called SenderHandle with a size of 16 bits. This parameter is always returned by the called method together with the answer and enables thesender to associate the answer message with its command message. Since MOST

62

4: Application Framework

Specification 3.0, the corresponding operation types without SenderHandle andwithout the suffix “Ack” are not used anymore.

Controller

Slave

FBlock.Inst.Function.StartAck(Data=´SenderHandle,Parameter Values’)
opt
FBlock.Inst.Function.ErrorAck(Data=’SenderHandle,ErrorCode,ErrorInfo’)Fig. 4.6: Starting a method with the operation StartAck

Operation StartAck (OPType: 0x8) is used to start a method for which a direct result is not expected or which triggers a continuous procedure (see fig. 4.6). This
corresponds to the operation Set for properties and also has the same OPType. For
StartAck, the only a feedback is in the form of an error message if an error has occurred.
Methods which generate a result and report it back to the initiator, are triggered bymeans of the operation StartResultAck (OPType: 0x6) (see fig. 4.7). The initiator
is informed of the results of the execution by means of a message with the operation
ResultAck (OPType: 0xD), if no error has occurred during the execution.
If the calculation of the result takes longer (more than 100 ms), the initiator is informed every 100 ms  of the ongoing calculation by means of a ProcessingAck
message (OPType: 0xA). Depending on the method, it is also possible that intermediate results are transmitted with the processing message to indicate the progress ofthe function execution. The correct handling of processing messages and the appropriate error handling is important to guarantee the responsiveness of an application
when implementing interactive HMIs.



The timings described here are standard values as defined by the MOST Specification. However, they can be defined differently for individual methods or by the system integrator for the whole system.

4.2 Application Protocol

Controller

63

Slave

FBlock.Inst.Function.StartResultAck(Data=´SenderHandle,Parameter Values´)loop
FBlock Inst Function ProcessingAck(Data=´SenderHandle, [Intermediate Values]´)

alt
FBlock.Inst.Function.ResultAck(Data=´SenderHandle,Result Values´)

FBlock.Inst.Function.ErrorAck(Data=´SenderHandle,ErrorCode,ErrorInfo´)Fig. 4.7: Starting a method with the operation StartResultAck

By calling the operation AbortAck (OPType: 0x7) on a running method, its current
processing can be interrupted. This is signaled by an error message with the error
code Method Aborted, which is sent both to the initiator of the method and to thesender of the abort request (in case the two are not the same).
Notification Mechanism
The MOST Specification defines a notification mechanism (see fig. 4.8) so that aController interested in a specific property does not have to constantly poll its current value using a Get message. When defining an FBlock, it is implicitly determined which properties support a notification mechanism.
For all of its properties supporting notifications, an FBlock administers a tablecalled Notification Matrix in which the addresses of those devices are entered thathave set a notification for the respective property. As soon as the value of one ofthese properties changes, the FBlock sends a status message (notification) with the
new value of the property to all devices listed in this table.
A Controller sets or deletes a notification by calling the function Notification(FktID: 0x401) of the corresponding FBlock. The first parameter (Control) indicatesthe operation (see the following listing). In another parameter (DeviceID), the address of the device requesting the notification is indicated. Finally, if required, thefollowing list of FktIDs describes for which functions a notification is requested.

64

4: Application Framework



SetAll: Requests a notification of the indicated device for all the FBlock’s
properties for which a notification is supported.



SetFunction: Requests a notification of the device for all the FBlock’s properties indicated in the subsequent list.

Controller

Slave

FBlock.Inst.Notification.Set(Data='SetFunction, DeviceID, FktID')
FBlock.Inst.Function.Status(Data='Parameter Values')
loop
When (value of property haschanged)

FBlock.Inst.Function.Status(Data='Parameter Values')

Fig. 4.8: Notification mechanismClearAll: Deletes all notifications of the indicated device for all notified properties of the FBlock.



ClearFunction: Deletes the notification of the device for the properties of the
FBlock indicated in the subsequent list.

If a notification of a property is set successfully, the FBlock sends a status message
with the current value as confirmation. An example for the use of the notification
mechanism is given in section 4.4.4.

Error Name

ErrorCodeDescription

FBlockID not available
InstID not available
FktID not available
OPType not available

0x01

Syntax error: FBlock does not exist

0x02
0x03
0x04

Invalid length

0x05

Parameter wrong/out of range

0x06

Syntax error: instance does not exits
Syntax error: function does not exist
Syntax error: operation is not defined
Length of the data field is not identicalwith the interface specification
One or more of the parameters were
wrong, i.e., not within the boundaries
specified for the function

4.2 Application Protocol

Error Name

ErrorCodeParameter not available

0x07

Reserved
Reserved
Reserved
Device Malfunction
Segmentation error

0x08
0x09
0x0A
0x0B
0x0C

Function specific

0x20

Busy

0x40

Not available

0x41

Processing Error

0x42

Method Aborted

0x43

System specific

0xC0 to0xEF

Supplier specific

0xF0 to 0xFE

65

Description
One or more of the parameters were within
the boundaries specified for the function,
but are not available at that time
Usage is deprecated
Usage is deprecated
Usage is deprecatedGeneral device error
Error during de-segmentation of messagesby the AMS
Function specific error
Function is available, but is currently being executed
Function is implemented in principle, but
is not available at the moment
General error during execution of amethodThis error code is used to indicate that amethod has been aborted by the AbortAck
operation
Error codes that are defined by a System
Integrator
Error codes that are defined by a device
manufacturer

Table 4.6: Error codes of the MOST protocol

Error Information
If an error occurs during the execution of a request, whether a property or a method,a message of the operation type Error or ErrorAck (OPType: 0xF or OPType:0x9) is returned. The error code (parameter ErrorCode) is transmitted in the first
byte of the data field. The second byte contains the parameter ErrorInfo with additional information depending on the error code, which will not be discussed here.
For a more detailed description see the MOST Specification [MOST 3.0].
There are some specific requirements concerning error responses in a MOST system. In order to avoid a cyclical sending of error information, error messages may
only be sent from the Slave to the Controller (with the exception of segmentation
errors).
The general error information shown in table 4.6 is specified by the MOST Specification.

66

4: Application Framework

4.3

MOST Function Blocks

This section goes into the details of the structure of an FBlock and describes theimportant aspects that have to be observed for its definition. Besides the general
structure of an FBlock, the concept of Function Classes is described, which provides guidelines for defining the individual functions of an FBlock.
Additionally, the system FBlocks, such as the NetBlock, required for administrative
tasks in a MOST system, are introduced in this section. Finally, the functions aredescribed that are required for the administration of streaming connections and forthe transmission of multimedia data.

4.3.1

Structure of a Function Block

The FBlock specification defines which functions belong to an FBlock of a specifictype. The type of an FBlock is determined by its FBlockID.
The MOST Cooperation standardizes a set of FBlock types, some of which are used
for system tasks, others describe certain application functionality. The latter are often extended by device manufacturers and System Integrators to integrate their own
proprietary functions. Other FBlock specifications are defined completely by the
System Integrator or device manufacturer – either because they define a proprietaryfunctionality or a new functionality for which a standardized FBlock specification
does not yet exist. The FBlocks standardized by the MOST Cooperation are collected in an function library (see section 4.4.1).
For all FBlocks, the following functions are required by the MOST Specification:


FktIDs (FktID: 0x000): A list of all functions implemented by the FBlock canbe queried by the property FktIDs. In order to compress this possibly long listof FktIDs, a coding is used in which only those FktIDs are included in the list,
in which there is a transition between a continuous area of implemented and of
non-implemented functions (for details see [MOST 3.0]).



FBlockInfo (FktID: 0x011): This mandatory function returns information
about the FBlock’s name and version, the version of the MOST Specification
the FBlock has been implemented for, the System Integrator in whose system
the FBlock will be used, and a string (FBlockType) that is assigned by the System Integrator to identify different instances of the same FBlock in the system(e.g., a left and right display unit for a rear-seat entertainment system).

Notification (FktID: 0x401): The property Notification must be implemented
by every FBlock that allows the setting of notifications for one or more of its
properties. By means of this property, a device can set or delete notifications(see section 4.2.2).

4.3 MOST Function Blocks
67

NotificationCheck (FktID: 0x402): The optional property NotificationCheckcan be used to check which notifications are currently set.

In addition to these functions, each FBlock must implement the functions from thecoordinated range that are indicated as conditional according to the respective precondition defined in the GeneralFBlock specification [GenFB]. Furthermore, allfunctions defined as mandatory in the corresponding FBlock specification have tobe implemented. Functions that are indicated as optional may be omitted.
When defining and deploying a MOST system, the System Integrator indicates indetail the devices that make up the system and the FBlocks which are to be implemented by each device. Usually, the System Integrator also indicates in detail,which functions are to be implemented by the individual FBlocks.

4.3.2

Function Classes

Function classes simplify the specification of an FBlock, by giving specific guidelines concerning the data types and operations of a function. A function class is assigned to a function in the FBlock specification and specifies particular settings forthe parameters of a function such as the maximum length of a sequence of characters. Additionally, a function class defines which operations can be executed on thecorresponding function. Finally, function classes are the basis for more complex,
compound data types, such as records or arrays.
Function classes enable a structured and uniform modeling of functions. Additionally, they support the use of tools for modeling and code generation and simplify
test automation.
If a function cannot be assigned to any of the function classes described below, it isassigned to the function class Unclassified Property for properties and Unclassified Method for methods.
The MOST Specification specifies the following simple function classes for properties, the status of which can be described with a single parameter:

Switch: The function class Switch encapsulates a Boolean parameter and describes a “switch” with two states, which can be set and read.



Number: The function class Number is used for the different parameter typesof signed and unsigned numerical values. This function class has the following
settings: the parameter type, its maximum and minimum value, an exponent defining the decimal place and the increment, by which the numerical value ischanged by Increment and Decrement operations.



Text: The function class Text is based on the parameter type String and definesa sequence of characters. Its settings indicate the maximum length of the string.

68

4: Application Framework

Enumeration: Enumeration types are described by the function class Enumeration and are based on an Unsigned Byte. This function class defines how many
elements the enumeration type has and what values they can have including an
textual description. For example, the function DeckStatus of the FBlock AuxIn
can have the values 0x00 for “Play”, 0x01 for “Stop”, 0x02 for “Pause”, etc.



BoolField: The function class BoolField defines a sequence of bits with alength of 8, 16, or 32 bits in total and is based on an Unsigned Byte, Word orLong, respectively. It is also permitted to structure the bit sequence into addressable elements of several consecutive bits. Leading bits, which are notused, remain empty.



BitSet: A property, whose status can be described by a parameter of type BitField, is assigned to the function class BitSet with the given length. As definedfor the parameter type BitField, its first half contains the mask and its second
half the data.

Container: Finally, the function class Container is used for further unstructured
data. This function class is based on a parameter of the type Stream, Classified
Stream or Short Stream. Its settings define the maximum allowed length.

Additional function classes are used to represent more complex data structures consisting of several parameters. For these function classes a leading parameter Position is used to indicate the individual elements which are to be accessed. Position
consists of the two parts PosX and PosY of one byte each. PosX indicates the position in the outer data structure, PosY the position in a possible inner data structure.
In the case of a two-dimensional array, PosX would indicate a certain row and PosY
a column. If PosX is not equal to zero and PosY is zero, the entire row of the arrayis used. With PosX and PosY zero the array is addressed as a whole.
For properties there are the following structured function classes:


Record: A Record consists of an arbitrary sequence of individual elements,
each with a certain function class, where individual elements can be accessedby the parameter PosX. Structured function classes, such as an Array, are also
allowed as elements (in this case PosY is used to address elements of the array).



Array: An Array describes a sequence of a maximum of 256 elements of thesame type, which can also be accessed individually by the parameter PosX. The
settings of the function class Array indicate the function class of the individual
elements and the maximum length of the Array.

DynamicArray: The DynamicArray is a variant of an Array, in which the individual elements are accessed via a 16-bit tag instead of PosX. In this case,longer arrays are possible. Additionally, functions for inserting and deleting
elements are defined. Since the tag of an element, unlike its position, does notchange when it is inserted or deleted, the DynamicArray is also well suited formore dynamic data structures.

4.3 MOST Function Blocks

69



LongArray: In the case of the LongArray, the individual elements are also accessed via a 16-bit tag. Additionally, a window mechanism is defined, bymeans of which a Controller defines a specific section (window) of the array.
Afterwards it is informed only about changes in this section, which enables anefficient HMI implementation for displaying a list where only the currenty visible section according to the screen size is updated (e.g., for displaying thephone book of a cell phone).



Map: The function class Map is similar to DynamicArray. However, in addition it is able to transmit the insertion or deletion of single or multiple lines via
notification. Therefore, updates for a function of class Map can be transmitted
very efficiently.

Sequence Property: The function class Sequence Property is a simple function
class, by means of which a sequence of individual elements can be set and read.
Multi-dimensional data types and the separate access to individual elements are
not supported.

For methods only the following two function classes are defined besides Unclassified Method:

Trigger: The function class Trigger describes a function class without parameters, which triggers a specific action.



Sequence Method: The function class Sequence Method is a function class formethods with a list of simple parameters.

4.3.3

Function Interfaces

Since MOST Specification 3.0 [MOST 3.0] the mechanism of function interfaces is
optional. Usually, the concept of function classes is only necessary for the definition of a function. Retrieving information about the function interface, i.e. the function class and its settings, during runtime is not common.
The MOST Specification specifies the optional operations GetInterface (OPType:0x5) to request a function’s function interface. The result is transmitted via the operation Interface (OPType: 0xE). The coding of the relevant information is detailed
in the MOST Specification.

4.3.4

System FBlocks

This section gives an overview of the FBlocks which are required by the MOST
Specification for the purpose of system administration. As mentioned earlier, there
are FBlocks implemented by all devices of a MOST system and FBlocks only provided by one specific device.

70

4: Application Framework

NetBlock (FBlockID:0x01)
The NetBlock is responsible for central tasks of the system administration concerning a certain MOST device. It must be implemented by every device in a MOST
system.
The most important functions of the NetBlock are described below. The complete
interface of NetBlock is specified in [NetBlock]:

FBlockIDs (FktID: 0x000): The function FBlockIDs returns a list of all active
application FBlocks that are offered by the device as pairs of FBlockID and InstID (system FBlocks like the NetBlock itself or the FBlock EnhancedTestability are not included). An FBlock may only be included in this function if it iscorrectly initialized and currently able to offer its functionality to a Controller
in the MOST system. Furthermore, the function FBlockIDs can be used to set
the InstID of an FBlock. Its main use is during the system scan of the NetworkMaster (see below).

DeviceInfo (FktID: 0x001): Queries characteristic parameters of the device,
such as the name of the manufacturer or a serial number.

Addressing Functions: Further functions provide information about the node
position address (NodePositionAddress, FktID: 0x002), the logical address(NodeAddress, FktID: 0x003), or the group address (GroupAddress, FktID:
0x004) of the device.



ShutDown (FktID: 0x006): The shutdown procedure of a MOST system iscontrolled through this function (see below).



ShutDownReason (FktID: 0x009): After start-up of a MOST system a uniqueController may query the reason for the shutdown from each device. In case ofa shutdown because of a failure (sudden signal off or critical unlock), each device that has detected such a failure returns respective information through thisfunction.



ImplFBlockIDs (FktID: 0x012): This optional function returns the list of
FBlockIDs of all FBlocks implemented by the device. In contrast to the function FBlockIDs, also the FBlocks that are not currently available can be queried.



RBDResult (FktID: 0x405): The result of a ring break diagnosis is transmittedwith this function. For details see chapter 8.

Boundary (FktID: 0xA03): This function is only available on a device whichacts as the TimingMaster. It enables the administration of the bandwidth allocation on the data link layer (read out and set). The corresponding mechanism is
described in section 5.1.

4.3 MOST Function Blocks

71

FBlock EnhancedTestability (FBlockID: 0x0F)
The FBlock EnhancedTestability (ET) is necessary to perform the tests required for
the Core Compliance of a MOST device (see [Core 3.0]) and must be implemented
by each device. These tests check basic system functions of the device, such as the
allocation of an address. Details of the functions of FBlock ET will not be given inthis context; it is described in detail in [FBET].
The FBlock ET offers functions for test automation. The function Reset (FktID:
0x221), for example, can be used to reset the device in order to start from a stablestate. It also contains functions for executing a functionality which can otherwise
not be triggered automatically, such as the function AutoWakeup (FktID: 0x201),
which simulates the spontaneous wake-up of the device.
FBlock NetworkMaster (FBlockID: 0x02)
The FBlock NetworkMaster is responsible for the central administration of the system configuration of a MOST system. It is thus mandatory for each MOST system
and must be implemented by a designated device. Often, a specific device is responsible for all master functionalities in a MOST system, which means that thedevice is usually not only NetworkMaster, but also TimingMaster, ConnectionMaster and PowerMaster. However, except for NetworkMaster and TimingMaster, thisis not mandatory.
The NetworkMaster administers the system configuration and thus the current system status of the MOST system. The system state is OK, if the current system configuration, that is the devices existing in the system and their FBlocks, are known to
the NetworkMaster; otherwise the system state is NotOK. The system is in the
NotOK state directly after the start-up or if an invalid configuration has occurred after a Network Change Event (e.g., due to an invalid device address).
In order to determine the system configuration during the start-up or after a Network Change Event, the NetworkMaster executes a system scan in which it queries
the FBlocks of all devices via the function FBlockIDs. This query is sent with thephysical device address.
If there is a valid configuration and the system status was NotOK, the system statechanges to OK and the NetworkMaster notifies the devices in the MOST system bymeans of a broadcast of the function Configuration. The parameter ConfigurationControl indicates the system state (in this case OK). Figure 4.9 shows the operational sequence of a system scan. In practice, the FBlocks also can be queried inparallel.
After the initial system scan, devices may also inform the NetworkMaster of new or
disabled FBlocks by sending a status message of the function FBlockIDs with a
new list of FBlocks. If the system state was OK before a system scan or the72

4: Application Framework

NetworkMaster is informed of a change in the FBlocks offered by a device, theNetworkMaster distributes the information about any added or disabled FBlocks to
the MOST system via the function Configuration. In the first case, the parameter
ConfigurationControl has the value NewExt, in the second case, it has the value
Invalid. With the additional parameter DeltaFBlockList, a list with FBlockIDs,
InstIDs, and – in case of NewExt – the logical address, of the respective FBlocks is
included.
If during a system scan a conflict occurs between the functional addresses of
FBlocks, which means that several instances of an FBlock have the same InstID, theNetworkMaster tries to resolve the conflict by resetting the InstID that was reported
last. If an error occurs, such as an invalid device address, which cannot be solved byresetting InstIDs, the NetworkMaster sets the system state to NotOK and thus triggers a new start-up of the system.
The information on the current configuration of the MOST system is stored by the
NetworkMaster in a central data base – the Central Registry. The Central Registry
stores the logical address of each device in the system, as well as a list of the implemented FBlocks with their InstIDs. The other devices in the system can query its
current configuration via the function CentralRegistry and thus determine the device address associated with the functional address of a communication partner. If
the higher levels of the Network Service are used, this mechanism is executed
automatically.
NetworkMaster

NetworkSlave 1

NetworkSlave 2...

NetworkSlave N

0x401.NetBlock.0x01.FBlockIDs.Get
LogAdr1.NetBlock.0x01.FBlockIDs.Status(Data='FBlock List')
0x402.NetBlock.0x02.FBlockIDs.Get
LogAdr2.NetBlock.0x02.FBlockIDs.Status(Data='FBlock List')
0x40N.NetBlock.N.FBlockIDs.Get
LogAdrN.NetBlock.N.FBlockIDs.Status(Data='FBlock List')

0x3C8.NetworkMaster.0x01.Configuration.Status(ConfigurationStatus='OK')

0x3C8.NetworkMaster.0x01.Configuration.Status(ConfigurationStatus='OK')

0x3C8.NetworkMaster.0x01.Configuration.Status(ConfigurationStatus='OK')

B

Fig. 4.9: Operational sequence of a system scan by the NetworkMaster

The FBlock NetworkMaster implements the following functions:

Configuration (FktID: 0xA00): With the function Configuration, the NetworkMaster disseminates information about the system state in a MOST systemby means of a broadcast (the parameter ConfigurationControl has the values4.3 MOST Function Blocks

73

OK or NotOK). Additionally, newly added or disabled FBlocks are announced(ConfigurationControl: NewExt or Invalid).
CentralRegistry (FktID: 0xA01): Enables the querying of the current Central
Registry. The complete Central Registry can be queried, all instances of a given
FBlock can be retrieved, or a specific instance for an FBlock is queried. The
function CentralRegistry returns a corresponding list of triplets of logical device address, FBlockID and InstID.



SystemAvail (FktID: 0xA10): The corresponding optional mechanism provides
information about the availability of the system. To this end the NetworkMaster
queries the function ImplFBlockIDs of all devices in the system. With the parameters DeviceAvail and FBlockAvail a Slave device may determine if all devices have correctly responded to the NetworkMaster and if all implemented
FBlocks are currently available.

FBlock ConnectionMaster (FBlockID: 0x03)
The FBlock ConnectionMaster is used for the administration of the streaming connections in the MOST system. It will be discussed in the next section.
FBlock PowerMaster (FBlockID: 0x04)
There is no particular FBlock specified for the PowerMaster. The FBlockID 0x04 is
only used for indicating the device with the corresponding functionality.
The PowerMaster is responsible for coordinating the shutdown of a MOST system.
This may be a regular shutdown, for example when the engine is switched off, or an
emergency measure, for example when the temperature is too high.
To shut down the other devices in the MOST system, the PowerMaster uses thefunction ShutDown of the NetBlock. It first announces the shutdown by sending a
Shutdown.StartAck(SenderHandle, Query) message as a broadcast. This enables theother devices to delay the shutdown by means of a ShutDown.ResultAck(SenderHandle, Suspend) message. Depending on the system architecture, an ongoing telephone call, for example, could prevent the shutdown.
The PowerMaster repeats the announcement of the shutdown at regular intervals. If
it does not receive a ShutDown.ResultAck(SenderHandle, Suspend) message as a
response, it initiates the actual procedure for shutting down by broadcasting themessage Shudown.StartAck(SenderHandle, Execute).
If a device detects a high temperature, it can force the shutdown of the system bybroadcasting a ShutDown.ResultAck(SenderHandle, TemperatureShutdown) message. The PowerMaster then executes the above described procedure for a normal
shutdown of the system.

74

4: Application Framework

4.3.5

Administration of Streaming Connections

Due to the fact that the transmission of multimedia data is a central application area
for a MOST system, the administration of the streaming connections, which areused to transmit audio and video data, plays a central role in a MOST system. The
following section deals with the mechanisms and interfaces provided for that purpose in the application layer.
Overview
In the MOST Specification, sources and sinks for multimedia data (audio andvideo) are conceptually associated with an FBlock. Each FBlock can have one ormore sources and – at the same time – one or more sinks. The telephone FBlock, forexample, has a source for voice output via the loudspeaker system of the vehicle, as
well as a sink for voice input via the vehicle’s microphone system.
Each source of an FBlock is addressed by the unambiguous tag SourceNr of type
Unsigned Byte. The sinks of an FBlock are identified correspondingly via the tag
SinkNr.
The function StreamDataInfo can be used to determine which sources and sinks are
implemented by a specific FBlock:StreamDataInfo (FktID: 0x116): Returns a list with the source numbers and alist with the sink numbers of the FBlock.

For a source, a streaming connection can be created, which is characterized by its
connection label and its bandwidth. The connection label is an unambiguous identifier and described by the parameter ConnectionLabel of type Unsigned Word. The
bandwidth is described by the parameter BlockWidth also of type Unsigned Word,
which defines how many bytes per MOST Frame are transmitted for this connection. One or more sinks can be attached to an existing connection.
Figure 4.10 shows the procedure used when establishing a streaming connection between the source of one FBlock and the sink of another FBlock. The respectivefunctions for sources and sinks are discussed in the next paragraph.

4.3 MOST Function Blocks

ConnectionMgmt

SourceFBlock75

SinkFBlock

opt
SourceInfo.Get(SourceNr=_)
SourceInfo.Status(SourceNr=_, ...)

Allocate.StartResultAck(SenderHandle=_, SourceNr=_)
Allocate.ResultAck(SenderHandle=_, SourceNr=_,
BlockWidth=_, ConnectionLabel=_)Connect.StartResultAck(SenderHandle=_, SinkNr=_, BlockWidth=_, ConnectionLabel=_)Connect.ResultAck(SenderHandle=_, SinkNr=_)
opt
SourceActivity.StartResultAck(SenderHandle=_, SourceNr=_, Activity=’On’)
SourceActivity.ResultAck(SenderHandle=_, SourceNr=_, Activity=’On’)

Fig.4.10: Establishment of a streaming connection

Functions for Sources
The MOST Specification requires the following functions for FBlocks with sourcesof multimedia data. These functions are specified in the specification of the General
FBlock [GenFB] and are implemented by every FBlock with a source:SourceInfo (FktID: 0x100): The property SourceInfo returns information about
the properties of the indicated source, such as its content type (e.g., PCM,
SPDF or MPEG2).



SourceName (FktID: 0x104): Returns a string that identifies the indicatedsource.



SourceActivity (FktID: 0x103): A source can be set to active or inactive using
the optional function SourceActivity. Accordingly, the source puts out data on
the attached streaming connection.



Allocate (FktID: 0x101): By means of the function Allocate, the FBlock is requested to create a streaming connection and to connect the indicated sourcewith it. At a certain point of time, only one source can be connected to a specific streaming connection.



AllocateExt (FktID: 0x108): Is similar to the function Allocate but contains afurther parameter ClkSrcLabel to indicate the connection label for the clock
source that is necessary for isochronous connections.



DeAllocate (FktID: 0x102): Disconnects the indicated source from its streaming connection and deallocates it at the TimingMaster.

76

4: Application Framework

Functions for Sinks
The following functions for FBlocks having a sink for multimedia data are definedaccordingly:


SinkInfo (0x110): Similar to SourceInfo, this property contains information
about the indicated sink.



SinkName (0x114): The identification string of the sink.



Mute (0x113): This function toggles the mute status of a connection. It also enables querying the corresponding current status of the sink, in case, for example, the status was set automatically by the FBlock to handle an error. The Mutefunction is optional, since more complex mechanisms for that purpose are usedin some systems.

Connect (0x111): Connects the indicated sink of the FBlock to the corresponding streaming connection. More than one sink can be connected to one streaming connection at one time.



DisConnect (0x112): Disconnects the indicated sink from its streaming connection.

FBlock ConnectionMaster (FBlockID: 0x03)
The MOST Specification defines the ConnectionMaster as a central administrative
unit for streaming connections. It establishes or removes streaming connections between given sources and sinks on request. Additionally, it administrates the information about all connections that exist in a system.
For this purpose, the FBlock ConnectionMaster implements the following functions(see [FBCM]):

BuildConnection (FktID: 0x200): Establishes a connection between a sourceand sink given by the respective FBlockIDs and InstIDs as well as the SourceNr and SinkNr. If necessary, a streaming connection is reserved. Basically,
the ConnectionMaster executes the procedure shown in figure 4.9.



RemoveConnection (FktID: 0x201): Removes an existing connection between
an indicated source and a sink. The corresponding streaming connection is released, if necessary.

ConnectionTable (FktID: 0x400): Keeps a list of all streaming connections
currently established in the system.

AvailableChannels (FktID: 0.401): Indicates the remaining bandwidth forstreaming connections in a MOST frame (in bytes).



MoveBoundary (FktID: 0x402): This function can be used to adjust theboundary, that is the available bandwidth between streaming and packet connections in a MOST system.

4.4 Standardized Application Interfaces

77

BoundaryChange (FktID: 0x403): A device can set a notification of this property to be informed about an onging boundary change.

When a central instance of an infotainment system administers the streaming connections throughout the system considering additional criteria, such as a priority of
applications, this instance often also adopts the tasks of the ConnectionMaster. The
FBlock ConnectionMaster is, in this case, often only implemented for debugging
purposes.

4.4Standardized Application Interfaces

Besides the system FBlocks the MOST Cooperation also standardizes FBlocks forthe interfaces of typical applications in vehicle infotainment systems.
This chapter provides an overview of the specified application interfaces. Some selected interfaces will be discussed in more detail as examples. Finally, a more detailed example for using an application FBlock in a MOST system is given, taking
as an example the AuxIn FBlock, which provides access to mobile MP3 players.

4.4.1

Function Library

The function catalog contains the current specifications for all FBlocks defined by
the MOST Specification. It contains not only the system FBlocks described in section 4.3.4, but also the interfaces standardized for applications. Table 4.7 shows thecurrent content of the function catalog with all FBlocks together with their most recent version number.

Kind

Administration



Name

FBlockID

Version 

GeneralFBlock

-

3.0.2

GeneralPlayer

-

2.5.1

NetBlock

0x01

3.0.1

NetworkMaster
ConnectionMaster

0x02
0x03

3.0.1
3.0.1

As of 2nd quarter 2010.

Description
Common coordinated functions
Coordinated functions for player
devices
System-FBlock
implemented byevery device
NetworkMaster
ConnectionMaster78

4: Application Framework

Kind

Audio

Drives

ReceiverCommunication



Name

FBlockID

Version

Vehicle0x05

1.6

Diagnosis

0x06

3.0

DebugMessages

0x07

1.0.1

Tool

0x0E

1.0

0x0F

3.0.1

0x22

2.4.2

AuxIn

0x24

3.5

MicrophoneInput

0x26

2.3.1

AudioTapePlayer

0x30

2.3.1

AudioDiskPlayer

0x31

2.4

DVDVideoPlayer
AmFmTuner

0x34
0x40

3.0
2.4.2

TMCTuner

0x41

2.3.1

TVTuner
DABTuner

0x42
0x43

2.3.2
3.0, 4.0

SatRadio

0x44

2.4

Telephone

0x50

2.3.2

GeneralPhonebook

0x51

2.3.2

NavigationSystem 1
GraphicDisplay

0x52
0x60

1.11
2.3

EnhancedTestability
AudioAmplifier

Only unofficially released by the MOST Cooperation.

Description
Interface for vehicle-related data
Access to diagnostic functions
Functions for controlling debug output
FBlock for test
purposes
Necessary forcompliance tests
AmplifierInterface for mobile consumer
electronic devices
Interface for microphones
Tape deck
CD player or
CD changer
DVD player
Radio tuner
Tuner for traffic
messages (TMC)
TV tuner
DAB tuner
Tuner for Satellite
Digital Audio Radio Service
Interface for connecting a mobile
telephone
Phonebook of atelephone
Navigation unit
Display unit

4.4 Standardized Application Interfaces

Kind

Name

UniqueFunctions

FBlockID

0xFF

79

VersionDescription

2.3

Collection of functions for the areaof unique functions

Table 4.7: FBlocks standardized by the MOST Cooperation

In table 2-2 of the MOST Specification [MOST 3.0], further FBlockIDs are defined(such as the FBlockID 0x54 for Bluetooth), that have no specifications in the function catalog. These are either specifications, which were not published officially, or
they are placeholders for historic or future definitions.

4.4.2

Common Functions (GeneralFBlock)

Coordinated functions (0x000 to 0x1FF) must be implemented in the same way by
all FBlocks. They are administered by the MOST Cooperation and described in thespecification of the General FBlock, which is currently available in the version 3.0[GenFB].
In addition to the functions mandatory for FBlocks (FktIDs, Notification and NotificationCheck), the GeneralFBlock describes functions for the administration ofdata structures, such as for inserting elements into an array (see section 4.3.2). The
functions for the administration of streaming connections are also defined here (seesection 4.3.5).
The GeneralFBlock only serves as a template. When defining an FBlock, the necessary functions from the current version of the GeneralFBlock are adopted as part of
the FBlock specification (i.e., they are not influenced by changes in a possibly newversion of the GeneralFBlock). If, however, an FBlock implements a coordinatedfunction, this function must not deviate from the specification in the GeneralFBlock.

4.4.3

Application Interfaces

In order to provide an insight into the application interfaces standardized by the
MOST function catalog, some of the interfaces for important applications from thearea of vehicle infotainment system are described here in more detail. For lack ofspace, it is not possible to give a detailed description of all FBlocks of the function
catalog.

80

4: Application Framework

CD Player, CD Changer (AudioDiskPlayer, FBlockID: 0x31)
The FBlock AudioDiskPlayer [FBADiskPl 2.4] describes a simple CD player or CDchanger. Since the MOST Cooperation defines FBlocks for different playing devices (besides the one for a CD player, there is one for a cassette player), their general functions are summarized in the FBlock GeneralPlayer [FBGenPl 2.5]. The
AudioDiskPlayer is a simple implementation of the GeneralPlayer. The latter also
provides additional functions such as for playing DVDs.
The FBlock AudioDiskPlayer describes the following groups of important functions:

The functions described in section 4.3.5 are implemented for accessing an audio source. Via this source, the audio data of the currently played track can bemade available in the MOST system, for example for output on an amplifier.



The current device status is contained in properties, such as DeckStatus, andcan be read out or set via corresponding operations. DeckStatus enables theexecution of the usual actions for a player device, such as play, pause, or stop.
Specific modes of the device can be set through further functions such as random, scan, or repeat.



Functions like AudioDiskInfo provide information about the inserted CD (orCDs), concerning the type of CD (audio, video or CDROM) and its format(e.g., CDDA, ISO9660). In the case of a CD changer, the status of the magazine (MagazineStatus) and the active CD (ActiveDisk) can be queried.

Additional functions give information concerning the play operation such as thenumber of the current track (TrackPosition) or its play time (TimePosition). A
Controller usually requests a notification for these functions, in order to indicate, for example, the remaining duration of a track on the user interface or to
be informed when the player changes to the next track in order to update themeta information for this track. To some extent, the play operation or the selection of the current track via TrackPosition can be influenced through thesefunctions.

Amplifier (AudioAmplifier, FBlockID: 0x22)
A device with an audio amplifier that receives audio data, processes, amplifies, andoutputs the data via the loudspeaker system of the car implements the FBlock
AudioAmplifier [FBAudioA 2.4]:
The audio data is received over one or more sinks, for which the FBlock implements the necessary functions as described in section 4.3.5.

Typical settings for the output of the audio signal (e.g., volume, bass, fader, andtreble) are controlled via corresponding functions.

4.4 Standardized Application Interfaces81

Additionally, the FBlock provides further functions to perform more specificadjustments of the amplifier functions such as activating and defining an equalizer function (EqualizerOnOff, EqualizerSettings).

Radio Tuner (AmFmTuner, FBlockID: 0x40)
The FBlock AmFmTuner [FBAmFmT 2.4] for an AM/FM tuner is described here
as an example for the FBlocks defined by the MOST Specification for different
kinds of radio tuners (e.g., the FBlock DABTuner for the digitial radio standard
DAB or the FBlock SDARS for a digital satellite radio).
The following main functions are defined by the specification of the FBlock
AmFmTuner:The functions ATFrequency, ATWaveband and ATStationInfo deliver information about the currently set frequency, the wave band and the station received(e.g., its name or program type).

A station scan is started with the function ATSeek where different settings are
possible (e.g., the direction of the scan, up or down).



The FBlock AmFmTuner supports the administration of several lists with station memories, though a simple tuner only needs to implement one station list.
By means of the function ATPresetSave, the current frequency can be stored ina specific list. The functions ATPresetList1 and ATPresetList2 provide accessto station lists with detailed information, the functions ATPresetShortList1 toATPresetShortList8 to lists with limited station information.

Further functions control the behavior of the AM/FM tuner when there are traffic reports. The function TAInfo indicates the name of the current traffic program. An active traffic report is signalized by the function TAMessage. It canbe interrupted by TAEscape. With TPSwitch the functionality for receiving traffic reports is switched on or off.

Additionally, the FBlock AmFmTuner has functions for different options tocontrol the behavior of the tuner. The function RDSSwitch, for example,
switches the use of the RDS signal on or off.

Connection of Mobile Devices (AuxIn, FBlockID: 0x24)
The FBlock AuxIn is also based on the FBlock GeneralPlayer (see [FBAuxIn 3.5])
and is implemented by a MOST device that acts as a gateway to connect mobile
MP3 players and other storage devices with music data to a MOST system.
The FBlock AuxIn supports mobile devices with their own administration of thestored music data such as Apple’s iPod, or devices on which the data is only stored
in a generic file system such as a USB stick. In the specification of the FBlock
AuxIn, the former are called database devices, the latter mass storage devices. Additionally, devices can also be connected via an analog audio input.

82

4: Application Framework

Additionally to the functions of the GeneralPlayer already described for the FBlock
AudioDiskPlayer, there are the following extensions:

Some functions are an adaptation of functions of the GeneralPlayer that became
necessary due to the much higher number of tracks or different access modes.
These are AuxTrackPosition as adaptation for TrackPosition, AuxTrackInformation as supplement of TrackInformation, and AuxTimeInformation as supplement of TimePosition.

Additional functions provide information about the connected device. Its deviceclass as well as its concrete type can be determined via the function AuxDeviceInfo. The function DeviceBrowsingCapabilities informs about the categories of music files that can be queried on a database device such as querying all
tracks of an artist or all tracks of a specific genre.

In order to query the possibly very comprehensive metadata for the music
tracks stored on a device, the FBlock AuxIn defines the function SelectAudioListInfo, which supports querying functions comparable to database queries.
Two filters indicate which tracks are to be considered during the query andwhich information about the tracks (e.g., title of the song, artist, and name of
the album) is to be sent back. In addition, the sorting sequence and a specificsection for the data to be transmitted can be indicated for optimizing the presentation on the display. SelectCurrentAudioListInfo is similar to SelectAudioListInfo. However, while SelectAudioListInfo considers all music files stored
on the attached device, SelectCurrentAudioListInfo only relates to the currently
selected track list.

With the function SelectAudioListFilter, the current list of the tracks for playback can be selected by setting a filter similar to the one used for querying in
SelectAudioListInfo. The currently active filter is read out via the function
CurrentAudioListFilter.



In version 3.5 of the AuxIn FBlock, the functions SelectCoverArt and SelectCurrentCoverArt have been added to request information about the coverart stored with the music files on the mobile device. The function RetrieveCoverArt can be used to retrieve the corresponding picture file.

Various other settings can be determined via additional functions; for example,
whether the metadata is to be transmitted via the Control Channel or the Packet
Data Channel (AsyncControlSwitch).

4.4.4

Example of Use (AuxIn)

This section explains the use of an FBlock in a MOST system, based on the example of the FBlock AuxIn. For this purpose, important message sequences when accessing the FBlock are described. These sequences are based on the ones described4.4 Standardized Application Interfaces

83

in the specification of the FBlock AuxIn [FBAuxIn 3.5]. They are only an example;
the individual tasks could be implemented in a different manner.
When initializing the system, the Controller sets the notifications it requires, for example, for updating the HMI representation (see fig. 4.11). In case of the FBlock
AuxIn, this is, amongst others, the status of the AuxIn device (DeckStatus), thenumber of the currently active track (AuxTrackPosition and TrackInformation), andits play time (TimePosition). Afterwards, the Controller is informed whenever thedevice has moved to the next track and can update the information on the HMI accordingly.
If the user requests a functionality of the connected device, the Controller must
transform this request into a corresponding command to the FBlock AuxIn. In thefollowing example (fig. 4.12) the device is set into play mode via the property
DeckStatus. The resulting changes are sent back through the previously notified
properties. The Controller uses this information, as well as the metadata of the now
playing track that it queries actively from the Slave, for updating its HMI representation.

AUXIn.Controller

AUXIn

Notification.Set(Control='SetFunction', FktIDList='0x200, 0201,
0x434, 0x439')
0x200 - DeckStatus
0x201 - TimePosition
0x434 - TrackInformation
0x439 - AuxTrackPosition

DeckStatus.Status(DeckStatus=_)
TimePosition.Status(Pos={x='2'}, Data={TrackTime=_})AuxTrackPosition.Status(Track=_)TrackInformation.Status(CurrentNumberTracks=_,
CurrentRelativeTrackPosition=_)Fig.4.11: Setting of notifications during initialization

Figure 4.13 shows the querying of information about the currently playing music
track. Via the function SelectCurrentAudioListInfo the identifier (tag), as well as84

4: Application Framework

the title, the artist, and the media type of the currently playing track is queried. The
current track is indicated by the value zero for the parameter Start. In the response
the actual position of the track in the current track list is contained; in our example
it is the first track of the current track list.
The Controller initiates this sequence, for example, if it has requested an action of
the FBlock AuxIn (see above) or if the Slave notifies a change of its status, for example that it has skipped to the next track.
If the user searches for a specific track by browsing through the media database of
the device via the HMI of the Controller, the Controller has to query the information for the corresponding lists of media files from the FBlock AuxIn. Usually, the
HMI offers different options for viewing the list of tracks, indicating specific properties of the tracks (artist, album, genre, songs).

AUXIn.Controller

AUXIn

DeckStatus.Set(DeckStatus=’Play’)
DeckStatus.Status(DeckStatus=’Play’)parUpdate Notifications
TimePosition.Status(Pos={x='2'}, Data={TrackTime=_})TrackInformation.Status(CurrentNumberTracks=_,
CurrentRelativeTrackPosition=_)
AuxTrackPosition.Status(Track=_)AuxTimeInformation.Status(Pos={x='2'}, Data={TotalTrackTime =_})

Request Current Metadata

Fig.4.12: Setting the play mode

4.4 Standardized Application Interfaces

AuxIn.Controller

85

AuxIn

SelectCurrentAudioListInfo.StartResultAck(SenderHandle=_, Start='0', Offset=_,NumberResults='1', ResultData='Tag, Title, Artist,
Mediatype')
SelectCurrentAudioListInfo.ResultAck(SenderHandle=_, Start='1', NumberResults='1',
ResultData='Tag, Title, Artist, Mediatype',
TotalNumberResults=_,
AudioMediaData='Metadata')

Fig. 4.13: Querying of metadata for the currently playing track

In the example given in figure 4.14, it is assumed that the user is looking for a specific artist and that three entries can be shown on one page of the HMI. Information
about the first three entries is thus queried via the function SelectAudioListInfo.
The result starts with the first track of the selected track list, consisting of the tag,artist, and mediatype and is sorted by the names of the artists. If the user scrolls
down in this list, the entries from the next page are queried by the Controller by increasing the starting point for the window by three. Usually the Controller builds up
a cache of the following tracks in advance in order to speed up scrolling.

AuxIn.Controller

AuxIn

SelectAudioListInfo.StartResultAck(SenderHandle=_, Start='1', NumberResults='3',
ResultData='Tag, Artist, MediaType',
SortOrder1='Artist', SortOrder2='-', SortOrder3='-',
FilterData= ‘HeaderInfoArtistFilter=“*”’)=SelectAudioListInfo.ResultAck(SenderHandle=_, Start='1', NumberResults=_,
ResultData='Tag, Artist, MediaType',
SortOrder1='Artist', SortOrder2='-', SortOrder3='-',
TotalNumberResults=_, AudioMediaData='{Tag=_,
HeaderInfoArtist=_, MediaType=''Playlist''},{Tag=_, HeaderInfoArtist=_,MediaType=''Playlist''}, {Tag=_,
HeaderInfoArtist=_, MediaType=''Playlist''}')

Fig. 4.14: Querying a list of artists

86

87

5

MOST Protocols

The MOST System uses either 44.1 kHz or 48 kHz sample rates for transmitting
digital audio signals in hi-fi quality. Devices with a different sample rate can beadapted to the network by means of a sample rate conversion. In MOST systems, it
is recommend to use 48 kHz.
Since the MOST System transmits the audio data synchronously, additional data
buffering is not needed. This reduces the complexity of the device and thereby
saves costs.

5.1

MOST Frame

The MOST system offers three frame types with different features: MOST25,
MOST50, and MOST150.

5.1.1

MOST25 FrameA MOST25 frame consists of 512 bits or 64 bytes. Sixty bytes are used for thetransmission of stream and packet data. Two bytes transport one part of the control
message that is made up of a total of 32 bytes for the administration of network andnodes. The control message is transported over 16 frames that are combined into
one block. The first and the last byte both contain control information for the frame.
Table 5.1 gives an overview.

Byte
0
1
2
….
60
61
62
63

Bit

Description

0-3
4-7
8-15
16-23
….
480-487488-495496-503

Preamble
Boundary Descriptor
Data Byte 0
Data Byte 1

504-510511

Data Byte 59
Control frame Byte 0
Control frame Byte 1
Frame control andstatus bits
Parity bit

Table 5.1: Structure of a MOST25 frame

88

5: MOST Protocols

Figure 5.1 shows the structure of a MOST25 frame.
64 Bytes = 512 Bits = 22,67 Microsecond @ 44,1 kHz Frame rate

packet data
0...9 Quadlets

Controldata
2 Bytes
Frame Control

Boundary Descriptor
Preamble

Parity Bit

Fig. 5.1: MOST25 frame [MOST 2.4]

Preamble
The preamble of the MOST25 frame is used for synchronizing the TimingSlaves tothe bit stream and for the initial identification of the frame. The slaves use a PLL
switch to synchronize to the network.
The TimingMaster generates the preamble based on its oscillator frequency or its
S/PDIF input signal.
After the bit stream has been carried over all MOST nodes, it arrives at the masterwith a phase shift caused by the signal propagation delay in each MOST node. The
master thus synchronizes itself to the oncoming frame by means of its PLL, recovers all the bits, regenerates the frame and thus compensates the phase shift.
Boundary Descriptor
The Streaming Data Channel and the Packet Data Channel share a total of 60 bytes,
which are available in a frame. The bandwidths of the two channels can be adapted
to their corresponding requirements via the Boundary Descriptor.
The boundary between the two areas can be shifted in steps of 4 bytes (a quadlet).
The Streaming Channel can thus have a width between 24 and 60 bytes (6 to 15
quadlets) and the Packet Data Channel a width between 0 and 36 bytes (0 to 9
quadlets).
The value of the Boundary Descriptor ranges from 6 to 15. It is administered by the
MOST Network Interface Controller of the TimingMaster.
If the value of the Boundary Descriptor is changed by the TimingMaster, all synchronous connections have to be re-established.

5.1 MOST Frame89

The bandwidth of the Streaming and the Packet Channel is calculated by the following formula:
Packet bandwidth = Total bandwidth – (Boundary * 4)

(Equation 5.1)

Streaming bandwidth = (Boundary * 4)
Packet bandwidth + Streaming bandwidth = 60
Frame Control
The last byte of the frame is used for controlling of the frame.
Parity Bit
The parity bit enables the detection of bit errors in the frame.

5.1.2

MOST50 Frame

The MOST50 generation uses a bit rate of 50 Mbit/s for doubling the bandwidth.
The name MOST50 derives from this fact. Even though the sample rate does notchange, the frame length can be increased to 1,024 bits or 128 bytes.
Figure 5.2 and table 5.2 show the structure of a MOST50 frame. The control data isplaced in 4 bytes in the 11-bytes header, which also contains the Boundary Descriptor and the System Lock Flag. The bandwidth of the stream and the packet data canbe adapted dynamically to current requirements without the need of re-establishing
the synchronous connections. It is controlled by the property NetBlock.Boundary.
The stream data can have a width of 0 to 29 quadlets plus one byte (0 to 117 bytes)
and the packet data can also consist of 0 to 29 quadlets (0 to 116 bytes).

packet data
0...29 Quadlets
Administration
System Lock Flag
Boundary Descriptor
4 Bytes Control Data

Fig. 5.2: MOST50 Frame [MOST 2.5]

90

5: MOST Protocols

The bandwidth of the Streaming and the Packet Channel is calculated by the following formula:
Packet bandwidth = Total bandwidth – (Boundary * 4) - 1
Streaming bandwidth = (Boundary * 4) + 1(Equation 5.2)

Packet bandwidth + Streaming bandwidth = 117

Byte

Bit

0-10

0-87

11-127

88-1023

Description
Administrative, includes
System Lock Flag
Boundary Descriptor
4 control data bytes
data bytes

Table 5.2: Structure of a MOST50 frame

5.1.3

MOST150 Frame

The MOST150 frame has a similar structure to MOST50. Using the same sample
rate und three times higher baud rate as MOST50, the frame length amounts to
3,072 bits or 384 bytes.

packet data
0...93 Quadlets
Administration
Preamble
System Lock flag
Shutdown Flag
Boundary Descriptor
4 Bytes Control Data

Fig. 5.3: MOST150 Frame [MOST 3.0]

Figure 5.3 and table 5.3 illustrate the structure of a MOST150 frame. The control
data and the Boundary Descriptor are also placed in 4 bytes in the 12-bytes header.
The bandwidth can be adapted dynamically too. The stream data can have a width

5.1 MOST Frame91

of 0 to 93 quadlets (0 to 372 bytes) and the packet data 0 to 93 quadlets (0 to 372
bytes) as well. It is possible to use the total available bandwidth both for streaming
data or for packet data.

Byte

Bit

Description
Administrative, includes

0-11

11-3830-95

96-3071Preamble

System Lock Flag

Shutdown Flag

Boundary Descriptor

4 control data bytes

data bytes

Table 5.3: Structure of a MOST150 frame

Boundary Descriptor
The Boundary Descriptor is also controlled by the property NetBlock.Boundary andcan be changed without the need of re-establish the synchronous connections. Only
the application on the node with the TimingMaster function can change the value.
The initial value is set in the TimingMaster’s configuration.
The bandwidth of the Streaming Channel and the Packet Data Channel is calculatedby the following formula:
Packet bandwidth = Total bandwidth – (Boundary * 4)
Streaming bandwidth = (Boundary * 4)
Packet bandwidth + Streaming bandwidth = 372
Table 5.4 summarizes the influence of the boundary value for all versions.

92

5: MOST Protocols

MOST25

MOST50

MOST150

Available bandwidth Available bandwidth Available bandwidth(in number of bytes (in number of bytes (in number of bytes
per frame)
per frame)
per frame)
NetBlock.
Boundary
0
1
2
3
4
5
6
…
14
15
16

Stream- Packet
ing Data Data

Stream- Packet
ing Data Data

n/a

24

36

56
60

4
0

…
29
30
…
92
93

Stream- Packet
ing Data Data

1
5
9
13
17
21
25

116
112
108
104
100
96
92

0
4
8
12
16
20
24

372
368
368
360
356
352
348

57
61
65

60
56
52

56
60
64

316
312
308

117

0

116
120

256
252

368
372

4
0

n/a
n/a

Table 5.4: Boundary influence on the bandwidth for MOST25, 50, 150

Streaming Data
Control Data

Synchronous
Control Messsage
Service

A/V Packetized
Isochronous
Streaming
QoS IP
Streaming

Message Transfer(single + segmented)

DiscreteFrame
Isochronous
Streaming

Isochronous

Network Service

Fig. 5.4: MOST data transport mechanisms

Packet Data

Packet Data
Transmission Service

5.2 MOST Data Transport Mechanisms

5.2

93

MOST Data Transport Mechanisms

MOST defines data transport mechanisms for control, streaming and packet data
(see fig 5.4). The three MOST versions do not support all mechanisms. The following paragraphs describe them.

5.3

Streaming Data

The MOST Specification Rev. 3.0 distinguishes between synchronous and isochronous data. The latter can be transported only by MOST150.
The bandwidth of the Streaming Data Channel depends on the Boundary Descriptor(see section 5.1.2) and the frame version. It can be calculated using the following
formula:BW  SBC  4  8 Bits  Fs @MOST25; MOST150(Equation 5.3)

BW  ( SBC  4  1)  8Bits  Fs @MOST50
BW:

Bandwidth

SBC:

Boundary Descriptor (synchronous bandwidth control)

Fs:

Sample rate

Summary

Sample rate
(kHz)
minimum bandwidth(Mbit/s)
maximum bandwidth(Mbit/s)

MOST25

MOST50

MOST150

44.1

48

48

8.467

0.384

0

21.16844.928142.848

Table 5.5: Bandwidth of the different frames

94
5.3.2

5: MOST Protocols

Synchronous Data

Synchronous data is used for the real-time transmission of audio and video data. Before the data can be transmitted a connection must be established by the ConnectionMaster, which uses the Application Message Service (AMS).
The NIC used a so-called Routing Engine (RE) for that purpose.
The INIC uses sockets instead of the Routing Engine. For this purpose, one socket
has to be created and connected at the interfaces to the frame (MOST network port)
and to the local resource (MediaLB or streaming port) (see also section 10.4.3).
Thus, up to 15 stereo connections (2x16 bits per channel) or 60 1-byte connections
can be established simultaneously on a MOST25 frame. MOST50 can transport up
to 29 stereo connections and MOST150 a maximum number of 93. Each connection
has exactly one source and an arbitrary number of sinks. The content of the frame
remains unmodified until the frame arrives back at the sending node.
The quasi-static establishment of connections on a channel is denominated as Time
Division Multiplexing (TDM). The data are transmitted cyclically in a specified
time pattern at the same frame position. There is no repetition in the case of communication errors. A valid value is then available during the next cycle.

5.3.3

Isochronous Data

MOST25/50 can solely transmit synchronous data. An MPEG data stream is artificially “stuffed” with bits, or the stream is converted (transcoded) to a fixed bit rate.
Sample rate converters are sometimes used for audio applications to adapt PCM audio data to the MOST frame rate. However, not all audio or video data streams canbe simply synchronized to this MOST time base.
MOST150 introduced isochronous transfer. Isochronous channels are handled inmuch the same way as synchronous channels in MOST: the required bandwidth isfirmly reserved, which means channels for isochronous data are allocated, and thedata is routed as needed. MOST150 can handle three different isochronous mechanisms designed for different applications. Accessing is provided by TDM and allocation of quasi-static physical channels.
A/V packetized isochronous streaming
This mechanism permits transfers of video data streams that arrive without any reference to the MOST time frame. The data is already consolidated in small data
packets, which can optionally include a time stamp. MPEG data streams that arecoded either with variable (VBR) or constant bit rates (CBR) are a typical example

5.3 Streaming Data95of this. A MOST transfer initially reserves the maximum isochronous bandwidth
required. Figure 5.5 shows this mechanism.

MPEG
StreamIsochronous Frame Buffer

INIC

Time

Fig. 5.5: A/V packetized isochronous streaming (source: SMSC Europa)

The data arriving at the MOST Network Interface Controller is transferred automatically by INIC to internal memory whose content is transferred cyclically via
MOST. The Network Interface Controller of a data sink can copy the isochronous
data from the bus to its internal memory, and pass it via a suitable interface on to
the external hardware—an MPEG decoder, for example. The whole handling of
MPEG data is encapsulated completely in the MOST150 INIC, so that all the application has to do is reserve the required isochronous bandwidth and configure thecorresponding connections.

TimingMaster

TSYN

TSI Port

TCLK

TSI Port

TDAT
Data
Source Device

Sink Device

MOST150
48 kHz

TDAT
TCLK
TSYN

Fig. 5.6: Isochronous datatransfer of MPEG data over
an isochronous port/socket
and the TSI (source. SMSC
Europe)Besides a range of standard interfaces, the MOST150 INIC includes a transport
stream interface (TSI), now an established standard for video chipsets. Figure 5.6
shows the isochronous data transmission of MPEG data via one isochronous
port/socket per node.

96

5: MOST Protocols

DiscreteFrame Isochronous streaming
Although audio data streams are synchronous in nature (a constant volume of data
per time unit that is dispatched together with a highly accurate clock signal), they
are often not synchronized to the same time base as MOST. One example is transfers of PCM audio data, which might have been sampled at a frequency of 44.1 (or96) kHz, via a MOST150 network operating at a MOST frame rate of 48 kHz. The
sample rate used for audio CDs is 44.1 kHz. Another example is the transfer of an
S/PDIF signal (Sony Philips Digital Interface or Sony Philips Digital Interconnect
Format) via MOST. S/PDIF is an interface standard used to interface audio data on
decoder chipsets and in general used in the home audio domain, using opticalTOSLINK or electric cinch and/or RCA jacks. Home audio equipment usually features components with one or more digital S/PDIF inputs or outputs. The interface
is used for unidirectional transfer of PCM audio data according to IEC 60958 orcompressed audio data according to IEC 61937 such as DTS, Dolby Digital (AC-3)
or THX. Using isochronous transfer, these types of data streams can be “tunneled”
via MOST, without the need to synchronize them to the MOST frame rate or convert the data with a sample rate converter.

TCLK
TSYN
e.g. 44.1 kHz

Data

RMCK
Port

Time Base
Sink Device

Source Device

RMCK recovered
Streaming Port

TDAT

Streaming Port

TimingMaster

TDAT
TCLK recovered
TSYN recovered
e.g. 44.1 kHz

MOST150
48 kHzFig. 5.7: Isochronous data transfer of audio data via two isochronous ports/sockets(source. SMSC Europe)

To transfer an audio signal isochronously, it is not enough to simply tunnel the data
via MOST. In addition, the time base has to be maintained. This means the timebase must be transferred and the sink needs to re-synthesize the clock with highprecision.
The MOST150 INIC features inputs for non-MOST clock signals. The incoming
signal needs to be sampled and the time base needs to be transferred along with thedata. The time base (representing the clock) is restored in the sink after transfer
through the network by a dedicated unit in the INIC, and the data is re-output at thisclock rate.

5.4 Packet Data Channel

97

Figure 5.7 shows the isochronous data transfer of audio data via two isochronous
ports/sockets, one for data and the other for the time base.
QoS Isochronous mode
QoS Isochronous mode is also called QoS IP (Streaming) and is presented in section 5.8.3.
The MOST Stream Transmission Specification [MOST Stream] describes theisochronous data in details.

5.4

Packet Data Channel

The Packet Data Channel provides transmission of longer data packets and control
data. Its bandwidth also depends on the Boundary Descriptor. It uses a data link
layer protocol and transports packet data which is not transmitted cyclically (seesection 5.7), such as the TCP/IP protocol or MOST High Protocol (MHP).
The MOST specification describes a total of four packet data protocols. Figure 5.6
shows the protocols for MOST25 and MOST 50, and figure 5.7 for MOST150.

5.4.1

Packet data protocol for MOST25 and MOST50

The protocols for MOST25 and MOST50 are used with two different data field
lengths (fig. 5.8). The 48-byte data link layer protocol transports up to 48 data bytes
and the other layer up to 1,014 data bytes.
48 bytes data link layer (MOST25)
Alternative data link layer (MOST25/50)
Size (bytes) 1

2

1

2

N
Data area

N = 48 bytes
N = 1014
4
CRC

Source address (own address)
Data area length = roundup((Data+2)/4)= 1...254 Quadlets
Target address
Arbitration

Fig. 5.8: Structure of the packet data protocols for MOST25 and MOST50

The NIC supports both data field lengths, but its internal cache is only sufficient for
the 48-bytes protocol. The INIC uses the 48-bytes protocol, if it is controlled via theI²C bus. For the 1,014 byte data link layer protocol, it requires MediaLB (see also
chapter 10).

98

5: MOST Protocols

The protocol header consists of the arbitration field (1 byte), in which the token isstored, the target address (2 bytes), the data field length (1 byte) and the source address (2 bytes). The protocol is secured by a CRC sum (4 bytes), which is automatically generated by the MOST Network Interface Controller. There is no automatic
retransmission if there is a CRC sum error. This has to be handled by the higher
layers.

5.4.2

Packet data protocol for MOST150

The packet data protocol of MOST150 has a different structure from MOST25/50
and provides two addressing mechanisms:


16 bit Target Address (classic MOST addressing)48 bit Target Address (MAC addressing)

The CRC sum is placed in front of the data field and the data length is part of theheader (fig. 5.9).
If the 16 bit addressing mode is used, the first 6 data bytes contain the header of the
MOST High protocol.
The 48 bit addressing is used by Ethernet over MOST. In this case the CRC sum is
calculated by the Ethernet FCS algorithm. See section 5.8.2 for more details.
Both addressing modes support low-level retries. The number of low-level retries
and the propagation time between the retries is defined by the System Integrator.
16 bit Target Address (classic MOST addressig)
48 bit Target Address (MAC addressing)
I

I

4

I=2
I=6

N = 6....1014 bytes
N = 0....1506 bytes

N
Data area

Size (bytes)
CRC

Source address (own address)
Target address
Arbitration
Length in bytes
Transmission status
Addressing type identifier (16 bit or 48 bit mode)

Fig. 5.9: Structure of the data link layer protocols for MOST150

5.4.3

Arbitration algorithm

Access control takes place on the packet data channel by means of a token (fig.
5.10). If none of the nodes wish to send data, the token is passed on from one node
to the next.

5.5 Control Channel

99

Address
0x400

Node A(TimingMaster)

Address
0x403

Node D

Token

Node B

Node C
Address
0x402

Address
0x401

Fig. 5.10: Ring bus structure with fournodes

If a node wishes to send data, it has to wait for the token. It takes the token from thebus and thus gains the exclusive access authorization for the packet data channel.
The node sends a single packet and subsequently places the token back onto thebus. If it has several packets to be sent, it has to wait for the token again.
The prioritization of the packet data transfer takes place via an access disclaimer of
the token, i.e. a node with a low priority lets the token pass by several times – inspite of ready-to-transmit state - before taking it from the bus. This gives othernodes a higher priority for taking the token.

5.5

Control Channel

The Control Channel provides Control Message Services (CMS) that are used for
network administration. It is generally specified for event-oriented transmissions at
low bandwidth and short packet lengths. The Control Channel is secured by a CRC
and has an ACK/NAK mechanism with automatic retry. The control messages provide single and segmented Application Message Services (AMS).
The following both sections introduce the different control messages in the three
versions.

5.5.1

CMS for MOST25

Fig. 5.11 shows the structure of the control message for MOST25.

100 5: MOST Protocols

Size (bytes)

8 Bit
FBlock ID

8 Bit
Inst ID

4

2

12 BitFkt ID2

1

4 Bit
Tel ID

4 Bit
Tel Len17 Bytes Data area

2

4 Bit
OP Type

Message type
Source address
Target address
Arbitration

12 Bytes
Data

2

2

CRC
Acknowledgement
Reserved

Fig. 5.11: Structure of a control message (source: [MOST 2.4]

In order to prevent the Control Channel from claiming too much bandwidth perframe, it is distributed over 16 frames which are combined into one block (see fig.
5.12). Each frame transports 2 bytes of the channel. The preamble of the first frameof a block has a specific bit pattern to identify the block.
16 Frames = 1 Block362.81 Microsecond @ 44.1 kHz Sample rate

1 Control date frame
32 Bytes
16 x 2 Bytes

Fig. 5.12: Mapping of the Control Channel onto the MOST25 Frame

The protocol of the Control Channel has a constant length of 32 bytes.
Arbitration
The arbitration according to the Carrier Sense Multiple Access (CSMA) procedure
relies on the first two frames (4 bytes). The access procedure guarantees fair bus allocation, even if the bus load is high, because the priority of a message is not dependent on the node position in the ring. The arbitration is executed automaticallyby the MOST Network Interface Controller.

5.5 Control Channel 101
Addresses
Bytes 4 and 5 contain the destination address, the two subsequent bytes contain thesource address.
Message Type
Byte 8 transports one of the following message types (fig. 5.11):
Normal message (0x00)

System messageoResource Allocate (0x03)oResource DeAllocate (0x04)

oRemote GetSource (0x05)

oRemote messages
Remote Read (0x01)



Remote Write (0x02)

Normal Messages
A normal message (message type: 0x00) contains data packets for the Control Message Service (CMS), i.e., it transports the data for modifying properties and starting
functions of a function block, as well as the resulting response messages. A CD
player, for example, can be controlled by means of a function block.
The actual data is transported in 17 data bytes. The normal messages can be sent to
one receiver (single cast), to a defined group of receivers (group cast) or to all nodes(broadcast).
System Messages
The system messages have a code between 0x03 and 0x05. They are used exclusively by the MOST Network Interface Controller and are not visible to the application. The system messages for the resource management, such as Resource Allocate(message type: 0x03) and Resource DeAllocate (message type: 0x04) can be dispatched by all stream data sources. However, they are exclusively received andevaluated by the TimingMaster.
Remote functions, such as Remote Read (message type: 0x01) and Remote Write(message type: 0x02) are additional system messages. Through these functions, a
NIC can write or read 1 to 8 data bytes into another interface controller. These functions are only intended for debugging and should not be used in the normal operating mode. The INIC no longer supports these message types, as it does not have aregister wall (see chapter 10).

102 5: MOST Protocols
Message type 0x05 characterizes the Remote GetSource message. Through thismessage, the source of a streaming channel can be ascertained. It is normally sent asa broadcast message and ascertains the physical, the logical and the group addressof the streaming source. If there are, by mistake, several sources for one channel,
the message can be sent as single-cast message, in order to ascertain the sources andto resolve the conflict.
Control
Message

Normal
Message

SystemMessageResource
Allocation

0x03

0x04

Resource
De-Allocation- Single cast
- Groupcast- Broadcast- Target is always the TimingMaster

0x05

RemoteMessage

Remote
GetSource

Remote
Read

0x00

0x01

RemoteWrite

0x02

Fig. 5.13: Message types (source: [DS 8104])CRC
The CRC sum enables the receiver to identify transmission errors.
Acknowledgement Flag
The receiver of a control message can inform the sender about error-free reception
by using the acknowledgement flag (byte 28 and 29). The following states are possible:Message successfully received

Cache blockedCRC error

The receiver can only write on the flag and has no possibility to reset it. Thus thesender can recognize, even in groupcast and broadcast messages that the message
did not arrive properly in at least one of the receivers. It can, however, not discern
which receiver is concerned.
By default, five repetitions are executed in case of communication errors. The number can be changed in the register bXRTY of the NIC (OS8104). For the INIC, the5.5 Control Channel 103
function RetryParameters is used. Before each repetition, the MOST Network Interface Controller (NIC) waits for a configurable number of blocks (11 by default). In
the NIC (OS8104), the number can be set in the bXTIM (transmit retry time) register. The INIC, again, uses the function RetryParameters.
If it cannot successfully send the telegram by the last retry, it informs the host controller.
Data Field
The 17 data bytes transport the application message The structure, having a DeviceID, function block ID (FBlockID), instance ID, function ID, operation code andthe related parameters, are very closely connected to the function blocks. The following syntax is used for the functional addressing on the application level:
DeviceID.FBlockID.InstID.FktID.OPType (Parameters)

Section 4.2 gives a detailed overview of that matter.
If a service needs more than 12 bytes for the parameters, the message must be segmented (TelID > 0). Additionally, the first data byte is used as telegram counter,i.e., there are only 11 data bytes available for the parameters. The first telegram has
the TelID 1, the counter is set to zero. All further telegrams have the TelID 2. The
counter continues from 0x01 to 0xFF and starts again with 0x00. The last telegram
has the TelID 3. The TelLen indicates the number of bytes per telegram, i.e., for the
TelID 1 or 2, the TelLen is always 12. It can be shorter for the TelID 0 or 3.
Data Rate
The number of control messages that can be transmitted each second depends on thesample rate. Only 62 of 64 transmitted blocks are available for control messages.
Two blocks are used for the intra-system network administration such as the transmission of the channel resource allocation table. Since 16 frames are required for
one control message, the number of messages per second is calculated according to
the following formula [Found 04]:

CM 
with:

CM:

62 Fs

 2,670 Msg / s @ 44.1kHz
64 16
Control messages per second(Equation 5.4)

Fs:
Sample rate
Since each message carries 19 bytes (17 bytes data + 2 bytes DeviceID), the grossdata rate (DRgross) is calculated as follows:

DRgross  CM *19 * 8Bits
 405.84kbits / s @ 44.1kHz(Equation 5.5)

104 5: MOST Protocols
After the successful transmission of a control message, each node has to pause fortwo messages, i.e., the net data rate (DRnet) is one third of the gross data rate, provided that no higher prioritized node needs to send data:
DRnet DR gross3

 135.28kbits / s @ 44.1kHz(Equation 5.6)

The real data rate also depends on the interface used at the NIC.

5.5.2

CMS for MOST50

MOST50 frames contain 4 bytes per frame for control data within the header.
Therefore, a CMS message is split into 4 byte/frame pieces. In contrast to the
MOST25 frame, the control message length can vary depending on the specifics ofthe message, hence a CMS is based on a variable number of frames. The result isbetter utilization of the bandwidth. The minimum number of single frames is 6
(TelLen = 0) for commands without payload and the maximum number of single
frames is 9 (TelLen = 12). Figure 5.14 shows the control message structure. CMS
messages with a payload greater than 12 bytes are transported by segmented transfer and have a maximum length of 65535 bytes. Like MOST25, it covers the AMS.
The Message type no longer exits.
Control Message Service
Application Message Service
Size (bits)

96(12 bytes)

16

Arbitration
Length
PACK
CACK

16

16
CRC

8
Fblock ID

8
Inst ID

12
Fkt ID4
OP Type4
Tel ID

4
Tel LenN Bytes
Data

Source address
Target address

Fig. 5.14: Control message structure of MOST50

The header contains 12 bytes with arbitration, message length, preemptive acknowledge (PACK) and complete acknowledge (CACK).
Preemptive acknowledge (PACK)The PACK byte is used for flow control. It is driven by the receiver and indicates either a receiver ready, full receive buffer or wrong target, leading to an aborted message.

5.5 Control Channel 105
Complete acknowledge (CACK)A complete acknowledge (CACK) sent at the end of the message is also driven by
the receiver and indicates a wrong CRC or successful transmission.

Data rate of a single frame
The number of messages per second is calculated according to the following formula:

CM 

Fs
number _ of _ frames(Equation 5.7)

CM max 48000
 8,000 @ 48kHz; TelLen  0
6

CM min 48000
 5,333 @ 48kHz; TelLen  129

If none of the messages transport additional payload (TelLen = 0), 8,000 Control
Messages per second is the best case. If all messages have the maximum size of
payload (TelLen = 12) the result is 5,333 messages/s.
Payloadmin amounts to 7 bytes (DeviceID, FBlockID, InstID, OPType, TelID, TelLen) and payloadmax amounts to 19 bytes (payloadmin + 12 bytes data). Therefore,
the net rate is calculated with following formulas:

DRgross _ min  CM max * payload min * 8Bits 8,000 * 7 * 8Bits
 448kbit / s @ 48kHz; TelLen  0

DRnet _ min 

DRgross _ min3

 149.33kbit / s @ 48kHz; TelLen  0

DRgross _ max  CM min * payload max * 8Bits
 5,333 *19 * 8Bits
 810.62kbit / s @ 48kHz; TelLen  12

106 5: MOST Protocols

DRnet _ max 

DRgross _ max
3 270.21kbit / s @ 48kHz; TelLen  12

MOST50 has a theoretical minimum net data rate of 149.33 kbit/s and a theoreticalmaximum net data rate of 270.21 kbit/s.

5.5.3

CMS for MOST150

MOST150 is similar to MOST50. The frames also contain 4 bytes per frame forcontrol data within the header. The control message length also can vary dependingon the specifics of the message. The minimum number of single frames is 6 (TelLen= 0) for commands without payload and the maximum number of single frames is
18 (TelLen = 45). Figure 5.15 shows the control message structure. CMS with the
payload greater than 45 bytes are transported by segmented transfer and have amaximum length of 65535 bytes. MOST High protocol over the Control Channel is
no longer supported.

Application Message Service
8
Fblock ID

Size (bits)

96(12 Bytes)

16

Arbitration
LengthPACK
CACK
PIndex

16

16
CRC

8
Inst ID

12
Fkt ID4
OP Type32
4
4Message ID
Tel ID

12
Tel LenN Bytes
Data

Source address
Target address

Fig. 5.15: Control message structure of MOST150 single frame

The header contains— additional compared to MOST50—the PIndex. The PIndex
increments with each new control message sent by a particular node. It stays constant for low-level retries.
The Message ID covers the AMS parameters FBlockID, InstID, FktID and OPType.
AMS sets the last 4 bits of the Message ID to 0x0F in the case of a segmentation
error.

5.5 Control Channel 107
Data rate of a single frame
The number of messages per second is calculated according to the following formula:

CM 

Fs
number _ of _ frames(Equation 5.8)

CM max 48000
 8,000 @ 48kHz; TelLen  0
6

CM min 48000
 2,666 @ 48kHz; TelLen  45
18

If none of the messages transport additional payload (TelLen = 0), 8,000 Control
Messages per second is the best case. If all messages have the maximum size of
payload (TelLen = 45) the result is 2,666 messages/s.
Payloadmin amounts to 8 bytes (6 bytes Message ID, TelID, TelLen and 2 bytes target address) and payloadmax amounts to 53 bytes (payloadmin + 45 bytes data).
Therefore, the net rate is calculated with following formulas:

DRgross _ min  CM max * payload min * 8Bits 8,000 * 8 * 8Bits
 512kbit / s @ 48kHz; TelLen  0

DRgross _ max  CM min * payload max * 8Bits
 2,666 * 53 * 8Bits
 1,130kbit / s @ 48kHz; TelLen  45

MOST150 has theoretical minimum net data rate of 512 kbit/s and a theoreticalmaximum net data rate of 1,130 kbit/s.
Note that a MOST device cannot use the overall available control message bandwidth of the MOST network, typically caused by limitations by the IO interface, thedevice driver, the network stack and the application.

108 5: MOST Protocols
5.6

Summary
MOST25

MOST50

MOST150

Frame size (bits)

512

1024

3072

Sample rate
(kHz)

44.1

48

48

24

0

0

60

117

372

8.467

0.384

0

21.16844.928142.848

0

0

0

36

116

372

0

0

0

10.841 1

44.544142.848

2
16

4
6

4
6

16

9

18

19
19

7
19

8
53

405.84448

512405.84810.62

1130

Streaming data
Minimum(bytes)Maximum(bytes)minimum bandwidth(Mbit/s)
maximum bandwidth(Mbit/s)
Packet data
Minimum(bytes)Maximum(bytes)minimum bandwidth(Mbit/s)
maximum bandwidth(Mbit/s)
Control data
Bytes per frameMin. number of frames
Max. number offramesMin. data bytes
Max. data bytes
Min. gross bandwidth(kbit/s)Max. gross bandwidth(kbit/s)

Table 5.6: Summary of the frame parameters of MOST25, 50 and 150

1

for calculation see appendix B

5.7 Addressing 109

5.7

Addressing

On level 2 of the ISO layer, the MOST network supports five modes of addressing
for the data link layer protocol and the Control Channel:
Internal Node Communication address (reserved for internal communication ina node)

Node position address (RxTxPos)



Logical node address (RxTxLog)

Group addressBroadcast address

Ethernet MAC address (only MOST150)

16 bit addresses are always used, except for the Ethernet MAC address (it is 6 byteslong). Table 5.7 shows the division of the address domains. The four uppermost address bits are currently not in use; they are, however, reserved for future applications.
Address rangeMode

0x0000...0x000F
0x0010…0x00FF
0x0100…0x013F
0x0140…0x02FF
0x0300…0x03C7
0x03C80x03C9…0x03FE
0x03FF0x0400…0x043F
0x0440....0x04FF
0x0500…0x0FEF
0x0FF00x0FF1…0x0FFD
0x0FFE
0x0FFF
0x1000…0xFFFE
0xFFFF

Internal Communication
Static address range
Dynamic calculated ( 0x0100+POS) address range
Logic address range; statically assigned
Group addresses
Blocking broadcast addressGroup addresses
Unblocking broadcast address
Node position (0x0400 + POS) address range
Reserved
Logic address range; statically assigned
Optional debug address
Reserved
Init address of Network Service
Init address of MOST Network Interface Controller
Reserved for future use
Uninitialized logical node address

Table 5.7: Address ranges of the MOST network [MOST 3.0]

Node Position Address (RxTxPos)
Each node of a MOST network has a unique identification which depends on its position in the ring and is dynamically ascertained by the link layer. This identification

110 5: MOST Protocols
is called node position. The TimingMaster always has node position 0x00, the following node 0x01, etc. (fig. 5.16). The maximum number of nodes in the ring is 64.
By means of the node position, the delay between signal source and signal sink can
be determined quite easily by the source informing the sink of its position and thesink determining the number of network nodes through which the signal has passed.
Node position
0x00

Node A
Node position
0x04

MOST frame(TimingMaster)

Node E

Node B(TimingSlave)(TimingSlave)

Node position
0x03

Node D

Node C(TimingSlave)(TimingSlave)

Node position
0x01

Node position
0x02

Fig. 5.16: MOST ring with the node addresses

The node position address is derived from the node position and is thus unambiguous in the network. When the system is started, the address is defined by the TimingMaster, as soon as the MOST Network Interface Controller is in lock status andhas opened the bypass. The address domain starts with the address 0x400, which isalways occupied by the TimingMaster. The node position address (RxTxPos) is calculated according to the following equation:
RxTxPos = 0x400+Pos
Since there is a possible maximum of 64 nodes in the ring, the last address is
0x043F; the remaining addresses are currently not being used.
Logical Node Address (RxTxLog)
The logical node address (RxTxLog) is a unique address in the network. After
power-up, all uninitialized nodes have the address 0xFFFF. After the initialization,
the logical node address is dynamically assigned according to the following equation (similar to the node position addresses) upon initialization of the network:
RxTxLog = 0x100+Pos5.7 Addressing 111
The TimingMaster has the logical address 0x100, the first node has the address
0x101, etc.
Anyhow, the system designer can statically assign the logical address in the address
domains 0x140…0x2FF and 0x500…0xFEF. The address can already point at thefunction of the nodes (e.g., first video monitor 0x200, second video monitor 0x201),
or at the position in the vehicle (e.g., 0x100 passenger cell left, 0x200 passenger cellright, 0x500 trunk).
In the NIC, the logical address is stored in two registers (bNAH and bNAL). The
INIC uses the function NodeAddress. Before the NIC accepts the address, it can
automatically check the uniqueness of the allocated address by means of the startaddress-initialization function.
Group Address (GA)The group address represents the allocation to a system class, such as amplifier, audio CD player or digital sound processor.
Group addresses occupy the address range 0x300…0x3C7 and 0x3C9…0x3FE. The
initial group address is derived from the function block ID according to the following equation:
GroupAddress = 0x300+FBlockID
The FBlockID of the characteristic FBlock of the node is used here, assuming that
this will be the most requested.
In the NIC, the group address is stored in the bGA (Group Address) register. The
INIC uses the function GroupAddress for modification.
Broadcast
A blocking broadcast address is a unique address (0x3C8) addressing all nodes in
the ring. All other control messages are delayed until all nodes have acknowledged
the received broadcast. This reduces the bandwidth if used excessively.
An unblocking broadcast message (0x03FF) does not block the transmission ofother control messages. This kind of transmission can be used for uncritical datatransmission, which might not necessarily be received by all devices.
Due to the fact that broadcast messages require extensively utilize system resources,
they should only be used for management functions, e.g., in order to receive the corresponding function blocks from all nodes during initialization. A further application area is querying all hardware and software versions of the components used ina car.

112 5: MOST Protocols
When a group address is used, the maximum data length of broadcast messages isreduced by one byte for the checksum.
Ethernet MAC Address
The Ethernet MAC address is a unique address in EUI-48 format and has a lengthof 48 bits (6 bytes) and is only supported within MOST150 networks. It is in the responsibility of each manufacturer to acquire its own OUI resp. block to build EUI48 and MAC addresses.
The address supports the Ethernet-typical address comparison modes:
Unicast (Perfect Filtering, 48 bit match)Multicast (Hash Filtering)

Broadcast (0xFFFF FFFF FFFF)



Promiscuous (unfiltered)

The mode is configured in the MOST Network Interface Controller.

5.8

Higher Protocols

The MOST Specification defines the MOST High Protocol and the adaptation layer
MAMAC (MOST Asynchronous Medium Access Control) for the connectionoriented transmission of packet data on the transport layer level of the OSI model.
This enables the TCP/IP stack to be attached to the data link layer protocol. Bymeans of these protocols, packet data is sent with individual frames or as segments,for example navigation data. MOST150 networks do no longer support MAMAC
because MOST150 offers a real Ethernet transmission.

5.8.1

MOST High Protocol (MHP)The MOST High Protocol is a connection-oriented protocol and uses some of themechanisms of the TCP protocol. However, the overhead for the control of the data
flow was reduced to a minimum. As it is shown in figure 5.17, the protocol is attached to the Network Services Layer I. It can be implemented on the Packet Data
Channel and is unidirectional, i.e. there is a transmitter and a receiver module. If
data is to be transmitted bidirectionally, two connections are necessary.

5.8 Higher Protocols 113

Network Service
Layer II

MOST High
ProtocolTx Section

Rx Section

Packet Data
Transmission Service

Network Service Layer I
MOST Network Interface Controller
Fig. 5.17: Typical layer structure of the MOST High Protocol (source: [PFLNet])

Application Viewpoint
From the point of view of the application, the MOST High Protocol is located between Network Services and the function blocks of a MOST device (see fig. 5.18).
The Controller sends application data to a function of a function block in the receiver. The interface between the Controller and the MOST High Protocol corresponds to the one for the control messages of the function blocks.
DeviceID.FBlockID.InstID.FktID.OPType(Data)

Since the protocol is a connection-oriented one, a communication always consists ofthree parts:
Connection establishment

Data transmission

Connection termination
FBlock(Controller)

FBlock(Controller)

FBlockFBlock

Func
tion

Func
tion

Application
ProtocolApplication
ProtocolNetwork Services
Layer II

FlowControl
MOST
High
Protocol

Data
Data
FlowControl
Data…

Network Services Layer I

MOST
High
ProtocolNetwork Service
Layer II

Network Services Layer I

Fig. 5.18: View of the application to the MOST High Protocol (according to [MHP])

114 5: MOST Protocols
Additionally, the receiver informs the transmitter about the correct reception of thedata by sending a positive acknowledgement, or requests the data again with of anegative acknowledgement. This is also characterized as flow control (FlowControl) (fig. 5.18).

MHP onControl
ChannelMHP on Packet Data Channel(legacy only)

1,512-bytes
1,014-bytes
48-bytes datalink layer pro- data link layer data link layer
protocolprotocol
tocol
48
1014
1524

Usable data bytes
Header length(bytes)

17
5

6

6

6

Flow control (bytes)

1

2

2

2

11

40

1006

1518

15

255

255

255

1...165

1....10200

1...65535

1…65535

Max. data field
length per frame(bytes)Max. user frames per
block
Bytes per block

Table 5.8: MHP parameter for the control channel and for the transmission in the Packet
Data Channel

PACKET
Block 1 (max. 64 kBytes)

Block m (max. 64 kBytes)

n-FrameFrame 1n-FrameFrame nFrame nFrame 1

FrACK
High-Cmd

Fig.5.19: Structure of the MOST High Protocol (source: [MHP])

5.8 Higher Protocols 115
ProtocolMHP differentiates between packet, blocks and frames (see fig. 5.19). A packet
consists of a number of blocks, which, in turn, consist of up to 256 frames. The
number of frames in a block and the maximum data field length of the frames depend on whether MHP was implemented on the Control Channel (legacy only) oron the Packet Data Channel (table 5.8). The block size is always limited to 64
Kbytes.

HighCmd

Name

Description

CA

Request Connection

F2
F3

FA

Start Connection
END Connection
from sender
END Connection
from receiver
Frame ACK

Indicates the existence of data, the priority of connection, the maximum number of usable data bytes
per frame, and the revision number of MHP,
which is provided by the senderCommand for establishing communication
Connection termination request by sender

FB

RequestFF

Multiple Frames Request
Adjust Rate

FC

F0
FD
F1

Ready for Data
Hold Connection
from Sender

FE

Hold Connection
from Receiver

Connection termination request by receiver
Acknowledge of the receiver about received frameor block
Request for a certain single frame or an entire
block
Request for several frames of the current block
Request from the receiver to increase or decrease
the transmission rate
Acknowledge for connection is established
Indicates the interruption/continuation of thecommunication by the sender, e.g., if the transmit
buffer is empty
Indicates the interruption/continuation of thecommunication by the receiver, e.g., if the receiverbuffer is full

Table 5.9: Commands of the MHP flow control (source: [MHIGH])

A frame consists of a Data Link Layer Header, which is structured analogously tothe header of a control message, and the Transport Layer Header. For a flow control
message (control data) the Transport Layer Header consists of the Command Token(High-Cmd). For a Data Frame (User Data Frame) it consists of the Frame Acknowledgement (FrACK). Figure 5.19 shows the frame structure.

116 5: MOST Protocols
Table 5.9 gives an overview of the commands of the flow control.

An acknowledgment can be sent for each frame of each block. Figure 5.20 shows asequence diagram for MHP, in which an acknowledge is sent after each block. The
individual steps can be understood on the basis of table 5.9. The 0-FRAME is thefirst frame of a block.

Fig. 5.20: MHP control and data flow

Additional information and the MSCs relating to the individual commands can befound in [MHIGH].

5.8 Higher Protocols 117

5.8.2

Ethernet over MOST

MOST Ethernet Packets
The MOST Packet Data Channel (PDC) is used for sending asynchronous packet
data and supports two different addressing formats:

16 bit addressing; MOST Data Packets (MDP)

48 bit addressing; MOST Ethernet Packets (MEP)

MDP and MEP packets can be transmitted simultaneously by every device in the
MOST network by sharing the bandwidth of the Packet Data Channel between thesepacket types. The arbitration mechanism guarantees fair access to the channel forevery device. The bandwidth of the PDC can be dynamically changed by adjusting
the Boundary Descriptor. The protocol is CRC protected and a packet is automatically retried if a CRC fail is detected by the receiver, or the receive buffers are full.
The MEP format supports 48 bit MAC addressing and is compliant with the IEEE
Ethernet standard (refer table 5.10).

MAC DestAddr

MAC SrcAddr

48 bits

48 bits

Data
Maximum 1506 bytes

CRC
32bitsTable 5.10: Structure of the 48 bit MAC address

The data field can include an optional 32 bits VLAN (IEEE 802.1Q) field. However, the 16 bits length/type field is mandatory.
The INIC stores the MAC address and carries out address filtering, i.e., the filter
can be set up to only pass packets to the EHC that are of interest to the application
running on the EHC. The 48 bit addressing format supports the following standard
IEEE Ethernet MAC address filter modes:
Unicast (Perfect Filtering, 48 bit match)Multicast (Hash Filtering)

Broadcast (0xFFFF FFFF FFFF)



Promiscuous (unfiltered)

MEP packets transmit standard IEEE Ethernet frames on the Packet Data Channel.
Therefore, a standard TCP/IP stack can be used without any change on top of the
MOST Ethernet Driver.
Note: A low-level filter mechanism must be implemented to move MEP data to the
MOST Ethernet Driver and MDP data to the standard MOST Network Services
framework. The filter is necessary because MDP and MEP packets share the samedata channel. Figure 5.21 shows the details.

118 5: MOST Protocols

Fig. 5.21: MOST Ethernet driver concept

5.8.3

MOST Isochronous QoS IP (Streaming)

The MOST isochronous transmission subclass QoS IP (Streaming) can be used fortransmitting packet data that requires guaranteed bandwidth, e.g., camera or video
server applications.
The MOST Packet Data Channel shares the bandwidth between all devices on the
MOST network. Therefore, it does not guarantee a certain bandwidth for an application. The QoS IP channel guarantees exclusive access to a certain bandwidth on the
MOST network for a source device. It supports both point-to-point and point-tomultipoint connections. Furthermore, it is unidirectional and connection oriented.
The connection is usually set up by a Connection Manager that instructs the source
to allocate bandwidth on the MOST network and then instructs the sink(s) to connect to this particular channel.
Native MOST-aware applications use the QoS IP channels directly because they areaware of the QoS IP channels.

5.8 Higher Protocols 119

5.8.4

MOST Ethernet with QoS IP

The MOST Ethernet driver can handle MEP packets on the Packet Data Channel aswell as QoS IP channels. It sets up single or multiple QoS IP channels for sending
QoS classified packets to all targets. All other packets, which are not QoS classified, are sent on the shared Packet Data Channel. With this approach, a standard
TCP/IP stack, IP-based communication protocols and network application can run
on top of the MOST Ethernet driver without any adaption.
If QoS IP is required, an application only tags the TOS field in the IP header of theoutgoing data, or it uses reserved ports for access to the QoS IP channels. Non QoStagged packets will always be sent over the shared Packet Data Channel. Figure5.22 shows the mechanism.

Fig. 5.22: MOST Ethernet with QoS

120 5: MOST Protocols
5.8.5

MAMAC

MAMAC (MOST Asynchronous Medium Access Control) is an adaptation layer
which enables a simple transmission of TCP/IP protocols over the Packet Data
Channel. It can be used simultaneously with the MHP and is distinguished via the
TelID (see fig. 5.19). MAMAC maps Ethernet versions 1 and 2, as well as SNAP
and LLC directly onto the Packet Data Channel. It is supported by MOST25 andMOST50. Further details can be found in [MAMAC].

121

6

Physical Layer

The MOST Physical Layer Specification specifies both optical and electrical technologies for the physical layer. The optical transmission layer has now been used
several years in the automotive area and is widely spread. It currently uses opticalfibers (polymer optical fibers, POF) made of polymethyl methacrylate (PMMA)
with a core diameter of 1 mm as transmission medium, in combination with lightemitting diodes (LEDs) in the red wavelength range as transmitters and silicon
photo diodes as receivers. The optical physical layer has been introduced with adata rate of 22.6 Mbit/s [MOST BaPhy], commonly shortened with the term
MOST25. The first edition of this book focused on that technology in detail. Higher
bandwidth requirements for today’s systems made it necessary to further develop
the optical physical layer. The MOST Optical Physical Layer Sub-Specification[MOST Phy150] is released as the follow-up specification with an increased bandwidth of 147.5 Mbit/s, which is described in the following sections as the
MOST150 technology. In addition to signal requirements, the transmission properties of polymer fibers and the currently used transceiver technologies will be discussed. The chapter concludes with an overview of further developments of electrical and optical physical bus layers.

6.1

Introduction

According to the OSI layer model, the term Physical Layer is characterized as thelowest level of a network. It thus represents the physical connection between two
MOST control components (MOST Network Interface Controller). The MOST
Physical Layer Basic Specification [MOST BaPhy] defines four specification points
SP1, SP2, SP3, and SP4 along this point-to-point connection (see fig. 6.1) and outlines the basic measurement techniques and parameters for different physical layer
technologies.
The Specification points SP1 and SP4 describe the electrical signal requirements
between a MOST NIC and a converter (e.g., electrical signal levels, electrical ramp
response and connection timeout, jitter requirements). The interface properties between a MOST device plug and a wiring harness are defined by the specification
points SP2 and SP3. In a system with an optical physical layer, the parameters at
SP2 and SP3 are, for example, the wavelength, optical power, optical rise and falltimes, and, moreover, the mechanical dimensions of the MOST device plugs.

122 6: Physical Layer
Before going into detail with respect to the individual interface requirements at the
specification points, basic properties of optical fibers and opto electronic transmitters and receivers will be introduced in the following sections. For further reading
regarding a detailed description of opto-electronic transmission technologies, refer
to [Gus 98], [Vog 02].

Fig. 6.1: Definition of the specification points SP1, SP2, SP3, and SP4 along a point-topoint connection

6.2

POF Plastic Optical Fibers

Optical fibers are utilized more and more frequently for applications with a highdata rate due to increasing EMC requirements (Electromagnetic Compatibility).
Transmission lines with optical fibers do not cause any interference radiation andare insensitive to electromagnetic interference irradiation (Electromagnetic Interference, EMI). In contrast to shielded electric data lines, optical fibers are, moreover,lighter and more flexible and can thus be used more easily. The following section
describes a number of important basic principles of POF optical fibers for MOST
applications.

6.2.1

Basic Principles

Optical fibers consist of a light-conducting core which is surrounded by an opticalcladding of a lower refractive index. Figure 6.2 shows a structural diagram of an
optical fiber. If a light ray is coupled into the front end of a fiber within the acceptance cone, the light is guided along the core-cladding interface due to total reflectance. The ray travels along a zigzag path and all the light is conducted inside theoptical fiber.
The widest angle under which light can be coupled into the front side of an opticalfiber is called acceptance angle or numerical aperture. The acceptance angle φa andthe numerical aperture NA are calculated from:6.2 POF Plastic Optical Fibers 12322
NA  sin  a  ncore ncladding(Equation 6.1)

where ncore is the refractive index of the optical fiber core and ncladding the refractive
index of the optical fiber cladding. The wider the difference of the refractive indicesof the core and the cladding material, the wider the acceptance angle or numericalaperture.

Fig. 6.2: Schematic diagram of lightpropagation through an optical fiber

Taking the standard polymer fiber for MOST applications with a core refractive index of ncore = 1.49 and ncladding = 1.40 as an example, a numerical aperture of 0.5 isresulting, corresponding to an acceptance angle φa of 30°. With a high numericalaperture, light can be coupled in more easily. This is particularly interesting if
LEDs, which have divergent radiation characteristics, are used as a light source.
A high numerical aperture has, however, the disadvantage of a high mode dispersion. Mode dispersion results from the different propagation delays of light rays,
which are coupled in at different angles φ. Light rays with a small angle φ travel
faster through the optical fiber than light rays with a wide angle φ. The mode dispersion results in distortions of a rectangular pulse along the optical fiber. Figure
6.3 shows the effects of mode dispersion in a diagram. An ideal rectangular pulse at
L0 expands after a length L1 by the value Δτ1 and after a length L2 by the value Δτ2.
The longer the optical fiber, the higher the resulting pulse distortion.

Fig. 6.3: Schematic diagram ofpulse widening

For a step-index fiber, the pulse distortion Δτ is calculated according to the formula:124 6: Physical Layer 

ncore ( ncore  ncladding )ncladding  c0

L

(Equation 6.2)

where c0 is the speed of light and L is the length of the optical fiber. The pulse distortion limits the maximum bit rate of the wave guide. The maximum bit rate can beapproximated by means of the equation:

B

1


(Equation 6.3)

Taking a standard polymer fiber for MOST applications with the core refractive index of ncore = 1.49 and ncladding = 1.40 as an example, one gets a pulse distortion of
about 320 ps for a length of one meter. Connections in a vehicle usually have amaximum length of 20 m, which, according to theory, results in a maximum permissible bit rate of 150 Mbit/s. In practice, the bit rates can be higher when transmitting signals via polymer fibers. This is due to the fact that not all possible lightrays with different launching angles need to be stimulated when the radiation source
emits directed radiation. In the most favorable case, only rays with a small angle φare present, which results in a lower mode dispersion. An overall conclusion regarding the maximum transmittable bit rate is thus not easy. In the case of specified
stimulation characteristics, bit rates of more than 500 Mbit/s can be reached for fiber lengths of about 20 m [Dau 01].

6.2.2

Polymer Fibers – Properties and Advantages

The properties of different core and cladding materials of polymer fibers for different applications have been examined since the late 60s [Wei 99]. Fibers with a coreof polymethyl methacrylate (PMMA) and a fluorinated acrylate of a lower refractive index extruded thereon, are used both as light guides for lighting and for shortrange transmission systems with a length of less than 100 m. In short transmission
ranges polymer fibers with a 1 mm diameter have advantages over glass fibers:Flexibility:
Plastic fibers are much more flexible compared to glass fibers of the same diameter. Fibers with a large core diameter of, e.g., 1mm have good bending
properties due to the high flexibility of the polymer material.



Large fiber diameter:
Due to the large fiber diameter and the high numerical aperture of about 0.5,
the adjusting tolerances for the transmitter and receiver elements are relatively
large. It is thus easy to position plastic optical fibers in front of a transmitter or
receiver element, as the tolerance requirements are not very high. Transmitterand receiver modules (transceiver) and plug-in connectors can therefore be6.2 POF Plastic Optical Fibers 125

manufactured cost-efficiently using injection molding, which is quite interesting for use in vehicles.
Easy to process:
Plastic fibers can be easily processed, as the material is soft. The surface can befinished by cutting, grinding or melting. The processing can be carried out withsimple hand tools and is not very time-consuming.

Resistant to contamination:
Due to the large fiber diameter, slight contaminations at the end surface of thefiber, such as dust or condensation of humidity, only cause little additional attenuation. Plastic fibers can thus be utilized under rough environmental conditions.



Low costs:
All the aforementioned advantages result in lower costs, compared to glass fibers. Particularly in cars, short-range connections of less than 20 m on the basisof polymer fibers have a very good price-performance ratio, since the systemcosts are basically determined by the price of connectors and transceivers, andby the installation and maintenance efforts.

Fig. 6.4: (a) Schematic diagram of the structure of a polymer fiber with buffer and cablecoating and (b) the magnified picture of a MOST POF

Figure 6.4 shows the structure of a polymer fiber with protective cladding, according to the requirements for use in vehicles. The PMMA fiber consists of an opticalcore with a diameter of 980 µm, which is coated with a 10 µm cladding material.
The overall diameter of the optical PMMA fiber thus amounts to 1 mm. The opticalfiber is surrounded by a black buffer (protective cladding), which is fixed to the optical fiber and cannot be stripped. A high detachment resistance is necessary, since
the optical contacts at the end of the fiber are attached to the buffer by means of laser welding or crimping (see section 6.3). A cable coating surrounds the buffer andprovides additional protection from mechanical damage and other influences, suchas humidity or vehicle operating fluids.

126 6: Physical Layer

Fig. 6.5: Typical attenuation spectrum of a PMMA fiber

Optical attenuation is an important parameter of an optical fiber. The attenuation ofan optical fiber is usually specified by the logarithmic attenuation coefficient α as
dB/m. Figure 6.5 shows the attenuation of a PMMA fiber depending on the wave
length. The attenuation spectrum of a standard step-index (SI) PMMA fiber has
three minima at 520 nm, 570 nm and 650nm in the visible wavelength range.
MOST applications use the window in the red wavelength range at 650 nm, as lowpriced transmitter and receiver elements are available for this wavelength. The attenuation minimum at 650 nm is 0.14 dB/m.

Fig. 6.6: Typical graph of theattenuation of a full launched
PMMA fiber depending on thebending radiusStandard PMMA harness fibers are qualified to a temperature range up to 85 °C.
For that reason, the use of standard PMMA fibers in vehicles usually is limited tothe interior. Since the introduction of optical fibers for MOST, the allowed
temperature range could be increased up to 105 °C. However, it may be necessary
to use heat protection in the installation spaces, where higher temperatures occur.
Polycarbonate fibers were developed for even higher temperature requirements and6.3 Contacting of PMMA Fibers 127

can endure up to 135 °C. The attenuation of these fibers, however, is higher; it is
0.4 dB/m at the minimum [Wei 99].
Next to deterioration possibly due to aging, the attenuation of an optical fiber during operation is mainly influenced by additional losses through bending. Figure 6.6
shows the attenuation of a PMMA fiber depending on the bending radius. At abending radius of less than 10 mm, the attenuation rises by more than 0.5 dB compared to the basic attenuation. At a bending radius of more than 25 mm, there is virtually no rise in attenuation due to bending.
Note: In order to prevent additional losses in a vehicle connection, the bending radius shall not go below 25 mm for general applications. This also ensures that thefiber is not damaged by too sharp bending when the connection is manufactured andinstalled into a vehicle.

6.3

Contacting of PMMA Fibers

Figure 6.7 gives examples of different contacting technologies for PMMA fibers.
For the crimp method, a metallic ferrule (usually made of brass) is mechanicallypressed onto the buffer. For the ultrasonic welding procedure, a plastic ferrule ismelted onto the buffer. For serial production it is very attractive to attach the ferruleby way of laser welding. A laser beam melts the buffer material with the ferrule material. This makes it necessary to use a ferrule material that is transparent to the laser beam so that the welding point can be set between buffer and ferrule. In order toreach a high absorbance at the buffer material, carbon particles are blended in when
the buffer is extruded. It is particularly important for high processing reliability oflaser welding that the laser welding beam be highly stable and that the absorbanceof the buffer material and the transparency of the ferrule are highly homogeneous.

Fig. 6.7: Contacting technologies
for polymer fibers (source: Tyco
Electronics)

Hand tools are available on the market for assembling optical fibers by means ofcrimping. Figure 6.8, left side, shows tools for stripping and cutting an optical fiber.
A metallic ferrule is subsequently attached to the fiber end by a crimping tool, as
shown in figure 6.8 at the right side.

128 6: Physical Layer

Fig. 6.8: Hand tools for assembling optical fibers(source: Rennsteig
Werkzeuge)

A number of manufacturers offer fully automatic machines for manufacturing laser
welded ferrules for serial production. Figure 6.9 shows an example of a fully automatic machine with several processing steps for cutting the POF fibers according to
the customer’s requirements, stripping the ends of the fibers and attaching the plastic ferrules by means of laser welding after finishing the end-face of the fiber andmeasuring the attenuation.

Fig. 6.9: Fully automatic machine
for assembling polymer fibers(source: Schäfer)The assembled optical fiber cables are delivered to a manufacturer of cable harnesses and are incorporated there into the complete cable harness which is then delivered to a car manufacturer. Specific limiting stresses, such as temperature, humidity and bending radius are to be observed during the entire logistics chain. If required, the optical fibers must be protected by bending radius limiters and dust protection covers (see chapter 16).
The use of inline connectors makes modular construction of the cable harness possible. Figure 6.10 shows an example of an inline connector by means of which two
fiber ferrules can be firmly connected by a guide sleeve and a catch mechanism. It
is to be considered that including such a kind of disconnection point may cause additional losses of up to 2 dB due to an air gap, an axial displacement and Fresnel reflections at the end faces of the fibers.
Note: If inline connectors are used, the additional attenuation of 2 dB has to be accounted for when designing the system (see section 6.5.3).´6.4 Opto-Electronic Transceivers 129

Fig. 6.10: Inline connector for optical fiber disconnection points (source: Tyco
Electronics)

6.4

Opto-Electronic Transceivers

Ever since MOST was established, LEDs (Light-Emitting Diodes) have been usedas transmitter units in the red wavelength range for converting electrical signals into
optical signals. PIN photo diodes are used as receivers. A component which incorporates both transmitter and receiver is called a transceiver (a fusion of the words
transmitter and receiver). The following sections will go into detail with regard tobasic properties of LEDs and PIN photo diodes. In addition, typical packaging designs of MOST transceivers will be introduced.

6.4.1

LED Transmitter Devices

Light-emitting diodes having an emission wavelength of 650 nm are attractive
transmitter units for cost-efficient PMMA networks of less than 100 MHz bandwidth. At 650 nm, LEDs are usually made from the compound semiconductor AlInGaP.
Figure 6.11 shows the schematic structure of a typical LED. On applying a voltage
in the forward direction, photons are generated at the p-n junction by recombining
carriers. The direction of the generated photons is statistically distributed, which results in the fact that not all photons are coupled out at the surface of the semiconductor crystal. The efficiency of a standard LED is thus only 2-4 %. It is possible toconsiderably increase the external efficiency of LEDs by means of suitable structuring measures and suitable packaging. LEDs are often designed into reflectors, inorder to utilize the rays emitting at the side. Mirror structures at the backside ofLEDs are used to reflect the rays hitting the base of the substrate back to the surface. The LED surface may be roughened or covered by a polymeric hood, which
results in higher out-coupling. If the necessary measures are taken, the external efficiency reached today can amount to more than 20 %.

130 6: Physical Layer

Fig. 6.11: Schematic diagram of an LED

At a forward current of between 10 and 40 mA the optical power of an LED for applications in data communication is typically between 0.1 and 1 mW. It is often
characterized by the logarithmic unit dBm (related to 1 mW optical power) and is
calculated by way of the following equation:

 P 
PdBm  10  log mW dBm
 1mW (Equation 6.4)

The optical power of 1 mW thus corresponds to 0 dBm; the optical power of
0.5 mW amounts to -3 dBm, which is 3 dB less.
The modulation bandwidth of a commercially available LED amounts to a maximum of about 100 MHz. The bandwidth can be increased by changing the doping
concentration in the active layer. However, the output power is further decreased
due to the inserted impurities. Another possibility of increasing the bandwidth ispeaking, as it is called, where the driving current at the start of a data pulse israised, thus achieving a shorter rise time. However, complex control circuits are required for that purpose in order to be able to control the overshooting behavior. It
seems that bandwidth and efficiency cannot be optimized at the same time.
In the early 90s resonant cavity LEDs (RCLEDs) were introduced for the first time.
In RCLEDs the light-emitting active layer is embedded between a short resonator,
by which an increase of efficiency and modulation bandwidth can be achieved.
Components with both higher bandwidths and a higher output performance can thus
be realized. Due to their specific structure, the performance of RCLEDs is, however, more sensitive to temperature than the performance of LEDs, which must becompensated for by a suitable driver. Recently manufacturers have started to offer
suitable driver-RCLED combinations [DS FCM110] which are designed for MOST
applications.
Due to their high efficiency and a modulation bandwidth of far more than 500 MHz,red laser diodes would be well suited for PMMA networks. At present, however,
the admissible surrounding temperature of available red laser diodes is restricted toca. 70 °C, which would require a complex component cooling, if these diodes areused.

6.4 Opto-Electronic Transceivers 131

6.4.2

PIN Photodiodes

Silicon-PIN photodiodes are used as cost-efficient receiver components for converting optical signals into electrical signals in a wavelength range of 400 nm to 1100
nm. Figure 6.12 shows the schematic structure of a PIN photodiode on the left sideand the responsivity RPh along the wavelength on the right side. The responsivity
increases virtually linearly from 0.32 A/W at 500 nm to 0.7 A/W at 900 nm. At
650 nm the responsivity is ca. 0.47 A/W. Large-area diodes are necessary for efficiently converting light of PMMA fibers with a core diameter of 1 mm. A large receiver area, however, also means a high capacity, which in turn reduces the bandwidth. With bandwidths of up to 100 MHz and photo diodes of 1 mm diameter a receiver sensitivity of less than -30 dBm can be achieved.

Fig. 6.12: Schematic diagram of a PIN photodiode and typical gradient of the responsivityof a silicon photodiode6.4.3

Transceiver Housing and Connectors

A couple of manufacturers have developed transceivers (Fiber Optic Transceiver,
FOT) with integrated opto-electronic components for MOST networks. Figure 6.13
shows an example of an LED transmitter and a PIN photodiode receiver for MOST.
The LED and the driver component, or the photodiode and the receiver amplifier as
the case may be, are attached onto a leadframe and encapsulated in a transparent
plastic material. Seven electrical connecting pins lead out of the plastic housing toprovide the contacts for current supply, differential data signals and other status orcontrol lines. The MOST Physical Layer Sub-Specification [MOST Phy150] describes this kind of package THM (Trough Hole Mount), because the optoelectronic components are mounted through PCB holes. The handling of the THM
package is well known from the MOST25 technique and appropriate standard processes have been established at the component manufacturers.

132 6: Physical Layer
LED

PhotodiodeLED Driver

PD AmplifierFig. 6.13: Transparently cast transmitterand receiver elements(source: Hamamatsu
Photonics)

The assignment of the individual electrical connecting pins is defined by the MOST
Specification. Figure 6.14 shows the used pin assignment. Both transmitter and receiver components each have supply connections (Vcc, with 3.3 V) and a groundconnection (GND). Besides the differential data input (Tx+ and Tx-) and data output (Rx+ and Rx-), the Reset (\RST) pin at the transmitter allows to switch on andoff the optical output at a defined time during startup and shutdown to avoid opticalglitches. The status pin at the receiver is used to set the MOST Network Interface
Controller into a ready-to-receive state as soon as the receiver receives data signals.
Further information concerning the electric circuit of the components can be gathered from the data sheet of the respective manufacturer.

Fig. 6.14: Typical pin assignment ofa THM packaged FOT

Since the introduction of the MOST150 technology, there is also an SMD packaged
transceiver available to be compatible with state-of-the-art assembly and soldering
processes. The SMD package shows better EMI performance, compared to the
THM package, and is basically qualified for even higher data rates up to the gigabit
region. Furthermore the use of the SMD technology results in more flexibility in the
supply chain, because it is no longer necessary to purchase the FOT together withthe connector and pigtail. The opto-electronic component can be ordered directlyfrom the FOT vendor with huge cost benefits.
Figure 6.15 shows the pin assignment and a sample of a SMD packaged transceiver. The transceiver package is based on the SOIC (Small Outline Integrated
Circuit) standard. To contact the fiber in the vertical direction a special spring6.4 Opto-Electronic Transceivers 133

mechanism is specified. The spring forces are defined to have both a soft plug-in for
the assembly and a sufficient holding force to confirm a stable connection of the fiber.

Fig. 6.15: SMD transceiverpinout and sample device(source: Melexis).

For both the THM packaged transceiver and the SMD packaged transceiver, there
are device connectors available to offer the end user a standardized connector interface for MOST. Figure 6.16 shows schematic drawings of device connectors, characterized as 2+0 and 4+40.

Fig. 6.16: Schematic and exploded drawing of a MOST150 2+0 header connector (left) anda MOST150 4+40 (right) header connector (source: Yazaki Corporation)

The designation indicates the number of optical and electrical contacts. The 2+0
connector, shown in the left hand side has two optical contacts (one for the transmitter and one for the receiver), and no electrical contacts. The 2+0 header connector features a compact design to connect the THM packaged transceivers to the wiring harness, as well as low costs. The 4+40 connector, shown in Figure 6.16 on theright hand side has four optical contacts, and 40 electrical contacts. Between the
SMD packaged transceiver and the device connector a flexible pigtail is used. In thecase of the flexible pigtail, the FOTs are outside the actual connector housing of thecontrol device. This has the advantage that the active components can be randomly
placed on the circuit board of the control device. It is thus easy to place the FOTs

134 6: Physical Layer
near the MOST Network Interface Controller and at the same time avoid electromagnetic interference problems. The pigtail consists of a standard high temperaturepolymer fiber with attached transceiver ferrules. A maximum insertion loss of 1.5
dB is allowed, including fiber attenuation, fiber mismatch and surface roughness. A
bending protector could be applied to the pigtail fiber to prevent a too low bending
radiusFig. 6.17: Connector variants for
MOST interfaces(source: Tyco Electronics)

Figure 6.17 shows an overview of typical standard interfaces for MOST. The assignment of the optical contacts is defined by the MOST standard, whereas the electrical contacts can be defined by the end user as desired. The MOST standard only
defines the connector housing at the control device. The connector at the wire harness is not part of the standard. Due to the nature of the wire harness connector,
however, a maximum permissible optical insertion attenuation of 2.5 dB is to be observed. A detailed definition of the device connector geometry can be gathered fromthe Interface-Drawings of the MOST Physical Layer Sub-Specification[MOST Phy150]. Further requirements, such as the plug-in or unplug force are
typical of a specific end user and thus not part of the MOST standard. Apart fromthe connector groups showed in figure 6.16, the MOST standard lists a 2+20 alternative.
The individual parts of a control device connector and a wire harness connector are
illustrated in example 6.18. The exploded drawing shows a 2+0 control device connector and a 2+0 wire harness connector, where the fiber ferrules are connected in
an internal housing. As required, a bending protector for the polymer fiber can be
attached to the wire harness connector so that the minimum admissible bending radius of 25 mm is observed. The individual parts of the interfaces are sold separately
by most connector manufacturers. Wire harness connectors with optional line
lengths can thus easily be produced by the users themselves. If it needs repair, thewire harness connector can be disassembled into its individual parts with little effort.

6.5 System Considerations for the MOST Physical Layer 135

Fig. 6.18: Exploded drawing of a 2+0 connector housing with wire harness connector(source: Yazaki Corporation)

6.5

System Considerations for the MOST Physical Layer

This section describes the electrical and optical parameters and requirements of thephysical bus layer. Before explaining the exact specification parameters, a numberof basic parameter definitions are stated. The section will be concluded by considering power budget and timing.

6.5.1

Basic Principles of Electrical and Optical Parameters

Data Rate and Coding

The data rate of MOST150 systems results from the product of the frame size (BPF,
bits per frame) of 3072 bits and the frame rate (Fs, frame synchronization). At the
typically used sampling rate 48 kHz, the required bit rate is 147.56 Mbit/s. The
pulse length UI (unit interval), which is used as the basic pulse length unit, is defined as the half bit transfer time and can be calculated with the equation 6.5:

UI 

1
2  Fs  BPF.

(Equation 6.5)

At a frame rate Fs = 48 kHz and the number of bits per frame (BPF = 3072), one
unit interval is 3.391 ns. The MOST150 encoding is according to a DC adaptive
coding (DCA). The DCA coding compensates DC offsets by limiting the accumulated DC offset contained in the data. Five different symbol lengths are defined,
while the shortest pulse is 2 UI and the longest 6 UI. Depending on the data content
there are 2, 3, 4, 5, and 6 UI but never 1 UI pulses (see fig. 6.19). By avoiding the

136 6: Physical Layer
1 UI pulse length, the needed transmission bandwidth is reduced. The 6 UI pulses
only appear as preamble at the beginning of a new data frame and serve for synchronization.

Fig. 6.19: Schematic view of the possible pulse length for MOST150

Figure 6.20 gives a schematic view of the influences of various effects which resultin a modification of the ideal rectangular pulse. The pulse width can differ slightly
from the 2, 3, 4, 5, and 6 UI widths. Due to variations of temperature, noise, nonlinearities of drivers, etc., duty cycle variations (pulse width variations) jitter (phase
distortions) is generated. The bandwidth of all components in the transmission sector limits the rise-time and fall-time of a pulse, and the control in driver and amplifier components causes overshoot and undershoot in the signal.

Fig. 6.20: Schematic diagram ofideal and real pulse shapes

The MOST Specification defines limit values for the maximum deviations from theideal signal at the interfaces SP1, SP2, SP3 and SP4 in order to reach an error rateof less than 10 9. Since the time-critical signal parameters are influenced by manyfactors, these effects will be described in detail in the following.
Timing Distortions

The MOST Specification combines the time-critical parameters under the genericterm timing distortions according to figure 6.21. The timing distortion alignment jitter Aj and duty cycle are effects which are characteristic for a single link. They are6.5 System Considerations for the MOST Physical Layer 137

relevant if the signal integrity at the specification points SP1, SP2, and SP4 ismeasured with an eye diagram. The alignment jitter is the jitter relative to the recovered clock. In MOST150 systems, the alignment jitter is observed for a bandwidth larger than 125 kHz, because the Phase-Locked Loop (PLL), used in the
MOST Network Interface Controller, is able to track and eliminate phase variations
up to this frequency. To measure alignment jitter, the MOST specification defines a“Golden PLL” model, given in the form of a low-pass transfer function with a cutoff frequency of 125 kHz. The timing distortions system clock deviation, wander
and transferred jitter Tj describe modifications in the timing which can propagate
over one or several active nodes. The accumulation of these timing distortions may
not hit the system margin for the Master Delay Tolerance (see section 6.5.4) andtherefore limits the maximum number of nodes in the network. Due to the low-passcharacteristic of a NIC, the jitter transfer in each node is bandwidth limited. Because of that, the NIC has an effect of a “Jitter Filter” and is able to eliminate jitterat a frequency up to 200 kHz.

Fig. 6.21: Overview of the timing-distortions

The MOST25 Physical Layer Specification defined maximum values for each timing distortion by a separate parameter. However, this specification did not allow
sharing system reserve between different types of timing distortions. Furthermore,
low bandwidth distortions, which basically can be eliminated by PLL tracking,made measurement results worse. For MOST150 systems, these issues have beensolved by using an eye diagram measurement and PLL triggering.
Eye Diagram and PLL Triggering

An eye diagram shows an overlay of all pulses a digital signal takes on during a bit
period (UI). The bit period is defined by the data clock, which is necessary tomeasure the eye pattern. Usually an eye diagram is acquired by using a reference
clock as a trigger. If the reference clock is not available as a discrete signal, avirtual reference clock can be recovered by using the PLL trigger method of a serial

138 6: Physical Layerdata analyzer. With each virtual trigger, the signal is sampled and stored in apersistence map.

Fig. 6.22: Example of an eye diagram measurement, indicating the eye mask (left) anddefinition of the transfer function for the Golden PLL and the Jitter Filter (right).

Figure 6.22 shows an example of an eye diagram on the left hand side, measured
with a PLL model according to the MOST150 “Golden PLL”, indicated on the righthand side of Figure 6.22. The advantage of eye diagram measurement is that thetiming tolerances for all kinds of timing distortions are shared. That means good
duty cycle conditions allow more alignment jitter or low jitter allows more duty cycle. The signal quality can be evaluated by comparing the acquired eye diagramwith an eye mask. The masks are keep out areas that shall not be touched by thesignal trace. For the eye diagram measurement, different masks for SP1, SP2, andSP4 are specified. Figure 6.22 indicates the specification parameters Ax, Bx, … Fx
for the link quality measurement, with the index x = 1, 2, 4 according to the specification point (SP) under investigation. To prevent exceeding the maximum voltage
levels at SP1 and SP4, further mask definitions with the parameters Gx and Hx haveto be considered. Details can be found in the Optical Physical Layer SubSpecification.
For a MOST system with several nodes, the transferred jitter is significant. Jittercan be passed on from slave to slave and possibly become so high that the NetworkMaster can no longer synchronize the MOST signal correctly due to the degradation. It is therefore important for the entire system that the sum of all jitter anddelay effects does not exceed the Master Delay Tolerance, which is discussed in detail in section 6.5.4. Figure 6.23 shows the procedure to measure transferred jitter.
After acquiring the waveform, the time-interval error (TIE) is calculated by thephase deviations between the waveform and the best matching fix clock signal. The
TIE graph then is filtered with the low-pass Jitter Filter characteristic, given in Figure 6.22 on the right hand. The parameter transferred jitter Jtr finally is calculated as6.5 System Considerations for the MOST Physical Layer 139

the root-mean-square sum of the filtered TIE graph. The edge frequency for the Jitter filter is set to the highest expected PLL performance, to include the whole frequency range that might be transferred trough a MOST node. For the acquisition of
the waveform, a scope with a deep memory of at least 10 Msamples is needed tomeasure also the low bandwidth jitter portion. For example, with a memory depthof 10 Msamples and a sampling rate of 10 Gsamples/s the maximum record lengthis 1 ms. This record length allows measurements down to the frequency of 1 kHz.
The transferred jitter is specified as a RMS value for SP1, SP2 and SP4.

Fig. 6.23: Procedure to measure the transferred jitter Jtr

Optical PowerAn important parameter for characterizing MOST components is the optical powerof a MOST transmitter (SP2) or the power to be coupled into a receiver (SP3). Figure 6.24 shows an optical pulse diagram and the corresponding definition of the optical power levels. The average optical power is thus defined by the parameter PAV(average power). The parameters optical high level b1 and optical low level b0 describe the levels of the 1 and 0 states. The level b0 is not equivalent to “light off”.
Due to the extinction ratio re = 10 log (b1/b0) dB, the specification indicates, however, the minimum ratio between the two levels. For MOST150 it is specified tomeasure the b0 and the b1 level at the shoulder of 5 or 6 UI Pulses within a measurement region between 2.5 and 4 UI, as shown in Fig 6.24.

140 6: Physical Layer

Fig. 6.24: Definition of the optical levels b1, b0 and PAV

Measurement Tools

For measuring the electrical signal parameters at SP1 and SP4, an active probe witha high bandwidth (>1,5 GHz), a minimum input capacity and a maximum input resistance is required, in order to prevent any distortion of the original signal. The optical specification points SP2 and SP3 shall be evaluated with a high speed OEC
with a bandwidth >750 MHz and a photo diode with a large active area is required,in order to capture enough light of the 1 mm PMMA fiber. In addition, the OEC
shall have a signal-to-noise ratio (SNR) better than 8:1. For measurements in thefield, the average optical power PAV is usually measured by a simple power measuring device. Various manufacturers offer calibrated portable measuring devices forthat purpose. It has to be observed that only the optical power at SP2 and SP3 ismeasured which is emitted at a diameter of 1 mm and within a numerical apertureof 0.5. Further information on this matter can be gathered from the MOST150 oPhy
Compliance Measurement Guideline [ComPhyL 150].

6.5.2

Optical and Electrical Requirements

The MOST Physical Layer Sub-Specification [MOST Phy150] defines the required
parameters for all specification interfaces SP1, SP2, SP3 and SP4, in order to ensurea reliable transmission of data. The automotive area demands that all parameters areobserved, even under the most unfavorable environmental conditions. The environmental conditions to be considered are always specific to a particular end user.
Some car makers got together and developed a recommendation titled Automotive
Application Recommendation for optical MOST Components [MOST AARTHM],[MOST AARSMD] for harmonizing the environmental requirements. Typical requirements are a temperature range of -40 °C to 95 °C, a humidity resistance of up
to 85 % at 95 °C and mechanical robustness during an operation period of ca.
11,250 hours and a life cycle of 15 years. The required tests (temperature cycles,6.5 System Considerations for the MOST Physical Layer 141

humidity cycles, mechanical impacts, EMC/EMI) for the qualification of a MOST
product are exactly defined in the application recommendations.
Electrical Specification at SP1

The signal levels at SP1 are defined by the LVDS standard. The transmission isbased on differential signaling, to avoid electromagnetic interference. The signal
has to fulfill all required parameters like alignment jitter, transfer jitter and the amplitude values. In addition, a new circuitry is defined for MOST150 to achieve awell-regulated startup and shutdown procedure.
Optical Specification at SP2

The peak wavelength of 650 nm corresponds to the attenuation minimum of PMMA
fibers in the red wavelength range. Due to the fact that the attenuation of PMMA fibers rises below and above 650 nm, the admissible wavelength range is restricted to
between 630 nm and 685 nm. For the same reason, the width of the spectrum is restricted to 30 nm (FWHM).
The optical spectrum for a Gaussian distribution is defined via the peak wavelengthand the width FWHM. This definition is not suited for asymmetrical spectra, as noclear peak wavelength can be defined. Figure 6.25 compares the symmetrical wavelength spectrum of an LED to an asymmetrical spectrum. Asymmetrical spectra areevaluated by an alternative definition via the central wavelength λc2 and the spectral
width (RMS) σλ2. The central wavelength and the spectral width can be calculated
from a measured spectrum. The center wavelength is calculated from: P
(i=500 nm…800 nm, i1 nm)
 
P
i

i

i

c2

(Equation 6.6)iiwhere Pi is the optical power at a specific wavelength λi. The spectral width is calculated from the following equation:

 P (   ) (i=500 nm…800 nm, i1 nm) (Equation 6.7)
P
2

i

c2

i

i

2

i

i

For a sufficiently exact measurement, the spectrometer used must have a signal-tonoise ratio of at least 200:1 and a resolution of less than 1 nm. In addition, the spectrum in the entire wavelength range from 500 nm to 800 nm is to be evaluated, as142 6: Physical Layerthe determination of the center wavelength and the spectral width becomes otherwise too inexact.

Fig. 6.25: Gaussian spectrum (continuous line) and asymmetrical spectrum (broken line) of light-emitting
diodesThe optical power at SP2 is specified between -8.5 dBm and -1.5 dBm. The lower
limit may not be less, so to ensure data recovering at the receiver. The upper limit isdefined in order to avoid overload or blinding the receiver. The parameter POFF2 of 50 dBm defines the maximum admissible power level for the light off state. It isnecessary to observe this level in order to be able to reliably switch off a subsequent
receiver. Even if no more optical alternating signals are transmitted, some receivercomponents react to a minimal amount of d.c. light and prevent the switch-off procedure (sleep-mode) of the MOST bus. The extinction ratio must be at least 10 dB
so that the responsivity of the receiver is not impaired.
The other timing parameters (transition, alignment, and transfer jitter) are slightly
relaxed compared to the specification at SP1, giving margin for slight distortions
during the electro-optical transformation. Additional definitions at SP2 are given by
the parameters positive overshoot, negative overshoot and high-level signal ripple.
These parameters limit the amount of overshoot in the optical signal. For a graphical summary of these parameters, refer to the figure in [MOST Phy150].
Optical Specification at SP3

The definition of the optical spectrum remains unchanged compared to SP2. The
dynamic range of the link is indicated by the parameter Popt3 ranging from -22 dBm
to -2 dBm.
For the optical data bus system with a data rate of around 150 Mbit/s, the bandwidth
limitation of the polymer optical fiber, discussed in section 6.2.1 Basic Principles
becomes considerable. The bandwidth limitation results in variations of the opticalsignal in vertical (amplitude) and horizontal (pulse width) direction. The MOST
Physical Layer Working Group conduct some research to determine the polymer fiber transfer function. The detailed analysis comes to the result that with a maximum

6.5 System Considerations for the MOST Physical Layer 143

link length of 15 m and a full launched fiber the -3 dB cut-off frequency is about 90
MHz [MOST AppTF]. The highest frequency of a MOST150 data pattern is 75
MHz. Therefore the system is close to the bandwidth limit but can fulfill the required signal integrity if the link length does not exceed 15 to 20 m. The worst case
input signal at SP3 can be calculated by the convolution of the worst case signal at
SP2 and the POF transfer function with a given link length and launch condition.
Electrical Specification at SP4

Similar to the specification point SP1, the electrical levels correspond to the LVDS
standard. The eye diagram of a measured electrical signal must not hit the keep out
area of the defined mask, indicating the allowed jitter and the LVDS voltage level.
These criteria allow evaluating the link quality, which describes the performance ofa single link without any system aspect. For a complete system characterization the
SP4 receiver tolerance has to be considered. The applied eye mask for defining thereceiver tolerance is much smaller than the link quality eye mask, taking the accumulation of jitter at each node in the network into account.

Fig. 6.26: Power budget of an optical MOST system between SP2 and SP3

6.5.3

Power Budget

The minimum permitted transmit power at SP2 and the receiver responsivity at SP3
determine the available optical power budget. Figure 6.26 shows the power budget
between the two interfaces SP2 and SP3. According to the illustration, a power
margin of 13.5 dB is calculated. Due to the fact that the insertion attenuation of
MOST connectors at the interfaces SP2 and SP3 of the control devices is 2.5 dB
each, the margin available for the wire harness is reduced to 8.5 dB.
The attenuation of the entire optical connection between two control devices must
not exceed the wire harness reserve of 8.5 dB. Attenuations on the transmission link
result from fiber attenuation, inline connectors and possibly from bending and ageing losses.

144 6: Physical Layer

Fig. 6.27: (a): Spectral attenuation of a PMMA POF and spectral output power of a red LED
at varying temperatures(b): Effective fiber attenuation depending on the center wavelength. The spectral width of
the transmit source is l = 30 nm.

As already mentioned in section 6.2.2, the fiber attenuation of a PMMA fiber is
0.14 dB/m at a wavelength of 650 nm. Both, the temperature dependent output
power and emission spectrum of LEDs, however, strongly influence the powerbudget of the transmission system. Figure 6.27 on the left shows a detail of the attenuation spectrum of a PMMA fiber between 600 nm and 700 nm and the emission
spectrum of a red LED at varying temperatures. The illustration clearly shows that ahigher attenuation than at the minimum at 650 nm is applied to a large part of theLED. Apart from that, the optical power decreases with increasing temperature, thecenter wavelength drifts to higher wavelengths with 0.16 nm/K and the spectral
width increases. Due to this wavelength drift a higher effective fiber attenuation αeff
must be assumed for the system consideration, according to the equation

 eff  

 (  )  P ( )

 P ( )d(Equation 6.8)

Figure 6.27 shows on the right the effective fiber attenuation of a PMMA fiber calculated from the above equation depending on the center wavelength, calculated for
an LED with a spectral width of 30 nm. The effective attenuation amounts up to
0.35 dB/m.
Note: If an additional increase in attenuation due to ageing is taken into account,the resulting effective attenuation of a PMMA fiber is up to 0.4 dB/m. This value
must be used for power budget considerations.

At an effective fiber attenuation of 0.4 dB/m and insertion losses of the individual
inline fiber connectors of 2 dB at the most, different wire harness concepts and their

6.5 System Considerations for the MOST Physical Layer 145

feasibility, as well as operational reliability including system reserves for assembling, bending, and ageing losses can be calculated.

6.5.4

Timing Requirements

In section 6.5.1 and 6.5.2, the timing requirements for the nodes of a MOST systemwere described. Compliance with the specified values at SP1, SP2, SP3 and SP4link quality (LQ) allows the proper operation of an individual point-to-point connection. Table 6.1 shows the specified timing parameters at a bit rate of 147.456
Mbit/s (1UI = 3.39 ns). The highest percentage of phase variation and jitter iscaused by the OEC at the receiver interface between SP3 and SP4. The link-leveltests use a pattern generator as a signal source. The pattern generator has to provide
a test signal according to the MOST150 test pattern, which can be downloaded as asupplement file to the Optical Physical Layer Sub-Specification. To prevent a modification of the test pattern, the Network Interface Controller has to be set in the retimed bypass mode, which deactivates the scrambling mechanism.

Parameters
Alignment Jitter
Transfer Jitter

SP1

SP2

SP3

SP4 (LQ)

SP4 (RT)

0.15 UI
50 psRMS

0.3 UI112 psRMS-

0.55 UI
230 psRMS

0.6 UI-

Table 6.1: Specific timing parameters at SP1, SP2, SP3 and SP4 link quality (LQ) and receiver tolerance (RT) at a bit rate of 147.456 Mbit/s

Additional to the link quality specification parameters, a limit for the SP4 ReceiverTolerance (RT) is specified. The SP4 Receiver Tolerance describes the minimum
Alignment Jitter tolerance of a NIC and the maximum tolerable alignment jitter that
may occur in any place in the network. The SP4 Receiver Tolerance is measured
with a system-level test, which uses live data from a fully formed MOST150 ring.
Using the same eye diagram methodologies developed in section 6.5.1, a measurement is taken at SP4 of any node in the ring. By taking the measurement in thisway, one can quantify the total jitter accumulation at every position of the ring. Thismeasurement is applicable for every node in the network at SP4.
The timing parameters of real components are, besides the variance due to production, significantly influenced by the received light power at SP3 and the surrounding temperature of the opto-electronic transceiver. Figure 6.28 shows an example ofa typical gradient of the timing parameter alignment jitter, depending on the opticalpower at SP3 at room temperature. In the example given, alignment jitter is quite
low in middle optical power range. Getting closer to the specification limit, the jitter
increases and the eye closes.

146 6: Physical Layer

Fig. 6.28: Typical gradient of the alignment jitter at SP4 depending on the light
power at SP3

In order to ensure that the entire system consisting of several nodes can operate
without errors, the sum of all jitter and delay effects must also be taken into consideration. In terms of the MOST Specification, these effects are described as systemdelay. The system delay can possibly accumulate to such an extent at the slavenodes in the ring that the TimingMaster can no longer correctly synchronize to theincoming signal. The range in which the TimingMaster can correctly process the incoming signal is called the Master Delay Tolerance. The Master Delay Tolerance isa property of the MOST Network Interface Controller in TimingMaster mode and islisted in its data specification. The maximum value is defined in the Physical Layer
Sub-Specification with 0.5/Fs. The Master Delay Tolerance of the MOST Network
Interface Controller used as TimingMaster can influence the maximum admissible
number of nodes in a MOST system. The MOST Physical Layer Sub-Specification[MOST Phy150] defines a maximum node number of N = 20 which is sufficient in
the automotive area.
The total Master Delay Tolerance (TMDT) is calculated from the formula:
m 1

m

n 1

n 1

TMDT  t D Rx ( Master)  t D Tx ( Master)   t D (n)   tW (n)...
...  t D Medium   

m

t
n 1

TJ

2

(Equa-( n)tion 6.9)
The value m indicates the number of nodes in the MOST system, tD(n) the delay pernode (caused by the INIC, transmitter, receiver, and medium), tW(n) the wander(phase drift) per node and link and tTJ(n) the transfer jitter per node. The exact extent of the individual delay values depends on the system and is influenced by thelength of the wiring, the characteristics of various transceivers and the working
temperature. To evaluate the maximum delay, it is thus necessary to exactly analyze
the system under realistic conditions.

6.6 Alternative Transmission Media 147

Figure 6.29 shows an example of a system with three nodes and the position of thedefinition points of the individual jitter parts. According to the specification, eachpoint-to-point connection causes a maximum transferred jitter of 230 ps and amaximum alignment jitter of 0.6 UI at SP4 of each node. After the signal of theTimingMaster in the first slave has been transmitted via the PLL to the SP1 interface, the transferred jitter is reduced according to the PLL filter characteristics(<230 ps). The jitter at SP1 of the second slave is made up of the accumulated partof the first and the second slave. Up to the interface SP4 of the TimingMaster, thejitter of the last link finally contributes to the total jitter, system delay respectively.

Fig. 6.29: Position of the measuring points for the Master Delay Tolerance TMDTTo measure the Master Delay Tolerance, a scope is connected to SP1 and SP4 of
the master device in the ring, as indicated in Figure 6.29. The MOST150 data
stream contains a period of 10 UI at the start of each frame. This long period can beused as a marker to measure the delay between any two points in the network. By
capturing at least one frame, the Master Delay Tolerance can be measured. The
measured value must not exceed the specified limit of 10 µs, if the sample rate is
48 kHz.

6.6

Alternative Transmission Media

After the introduction of the MOST system with PMMA fibers as transmission medium, the Physical Layer has been continuously enhanced over the last few years.
The main focus of this task was on the development of alternative electrical and optical transmission media for MOST systems with higher data rates

148 6: Physical Layer
At the present time, optical data buses on the basis of 1 mm plastic fibers and LEDs
in the red wavelength range are the most cost-efficient technology for point-to-pointconnections in the vehicle interior. Due to higher demands on the networking in vehicles, alternative optical and electrical transmission technologies have been further
developed in the last few years for future network generations. The corresponding
specifications are being worked on in the MOST working group aoPhy. The following sections will introduce these technologies.
Optical Physical Bus Layer with Laser Diodes and PCS Fibers

The operational limits of the PMMA/LED-based connections are determined by thelimited system margin of 13 dB, the temperature range limited to 85 °C and the limited bandwidth of ca. 100 to 200 Mbit/s. The solution to these limitations is the useof a 200 µm glass fiber with optical polymer cladding (Polymer Clad Silica, PCS),
which is distinguished by a low fiber attenuation and a temperature resistance of up
to 125 °C. Having a core diameter of 200 µm, the fibers are flexible enough to allow a minimum bending radius of less than 10 mm for a life cycle of 20 years in
automotive surroundings. In combination with vertically emitting laser diodes (vertical cavity surface emitting laser, VCSEL) the system margin and the bandwidth
can be increased.

Fig. 6.30: (a): Schematic diagram of the cable structure of a PCS fiber and(b): PCS fiber with ferrule

Figure 6.30 on the left shows the cable structure of a PCS fiber for automotive
applications. The fiber consists of a fused silica core with a diameter of 200 µm
which is surrounded by a 15 µm optical polymer cladding. Having a core refractive
index of 1.453 and a cladding refractive index of 1.405, the resulting aperture of the
PCS fiber is 0.37. As in the PMMA fiber, the optical fiber is surrounded by a black
buffer, in order to allow assembly of the fiber by means of laser welding. Figure6.30 on the right shows a PCS fiber where the cladding has been removed and an
assembled PCS fiber. Due to the fact that PCS fibers have a small core diameter,6.6 Alternative Transmission Media 149

there are higher demands on the tolerance at the fiber contacting points. It is,however, possible to produce suitable ferrules using common injection molding
procedures. Conventional cleaving procedures, where the fiber is subjected totension and laterally scored, can be used for processing the fiber end face. This
results in a flat end face with high surface quality at the point of rupture.
Alternatively, the fiber end face can be processed by means of a CO2 laser.
Figure 6.31 shows the typical attenuation spectrum of a PCS fiber. The attenuationin the wavelength range from 530 nm to 1100 nm is less than 20 dB/km and thus
smaller by about an order of magnitude than the minimum attenuation of POF at
140 dB/km at 650 nm.

Fig. 6.31: Typical attenuation
spectrum of a PCS fiber with
200 µm core diameter

Due to the attenuation minimum of PCS fibers at 850 nm, vertical emitters(VCSEL) on a GaAs basis are suited as transmitter elements. They can be modulated up to the GHz range (see fig. 6.32). In the data-com area VCSELs are widespread for short-range connections and are used for Gigabit Ethernet, for example,
up to a transmission distance of more than 200 m via multi-mode optical fibers.
VCSELs combine the advantages of LEDs and edge-emitting laser diodes and are
distinguished by low production costs, testability at the wafer level and a simple
structural design, similar to the one of LEDs. The circularly symmetrical beam profile, the small beam width and the low divergence permit a high coupling efficiency
in combination with PCS fibers. VCSELs have low threshold currents, a high efficiency, and a high modulation bandwidth of far more than 1 Gbit/s and can be controlled by simple driver circuits. The reliability of VCSEL components has been
proven in several studies. At temperatures of up to 125 °C, a lifetime of 10,000
hours can be reached.

150 6: Physical Layer

Fig. 6.32: Schematic diagram of a verticalcavity surface emitting laser diode (left)
and typical characteristic curve of a VCSEL
at 850 nm (right)

When a PCS fiber-based connection is used, the power budget can be increased
from 13.5 dB to 18 dB compared to a PMMA fiber-based network. This is illustrated in table 6.2. By means of a temperature-compensated VCSEL, a minimum
output power of -9 dBm with a simultaneous maximum output power of -1.5 dBmfor the laser category 1 can be obtained. The power budget is thus increased by
1 dB compared to present PMMA connections. The sensitivity of receivers with anactive surface of ca. 200 µm is at least -27 dBm, which increases the power budget
by additional 4 dB. The fiber attenuation of a PCS fiber is insignificant for the fiber
lengths that are commonly used.

Parameters

PMMA/LED System

PCS/VCSEL System

Max. output power
Min. output power
Sensitivity of receivers
Power budget-1.5 dBm-8.5 dBm-22 dB
13.5 dB-1.5 dBm-9 dBm-27 dBm
18 dB

Fiber attenuation
Connector interface loss
Inline connector interface loss

0.4 dB/m
2.5 dB
2 dB

0.02 dB/m
2.5 dB
2 dB

Table 6.2: Comparison between the power budget of a POF-LED system and a PCS-VCSEL
systemSince the power budget and the temperature resistance in PCS-VCSEL systems ishigher than in POF-LED systems, the existing limitations when installing the cables
can be bypassed. At least two additional plug-in connectors can be inserted between
two control devices in order to simplify installation of the wire harness.
A physical layer specification for the data rate of 25 Mbit/s is already available for
the PCS-VCSEL technology [MOST BaPhy]. For this purpose, some manufacturers
have developed prototypes of FOTs with integrated VCSEL components and photo
diodes for 200 µm fibers. Figure 6.33 shows the prototype of a transmitter with

6.6 Alternative Transmission Media 151

integrated VCSEL and laser driver. The components are encapsulated in a plastic
housing to implement a simple and low-cost package. The figure also showsdifferent versions of MOST transceivers of the 2+0, 2+4 and 2+40 type.

Fig. 6.33: VCSEL transmitter and driver in injection-molded housing (source: Finisar Advanced Optical Components Division) and modified MOST transceiver with VCSEL transmitter for PCS fibers (source: Yazaki Corporation)

At present, PCS-VCSEL systems are not yet being used in vehicles due to higher
mechanical tolerance demands on the components and resulting higher systemcosts. This technology will only become commonly used when the demands on data
rates or the power budget increase to such an extent that the LED-POF technology
comes up against its physical limits.

Fig. 6.34: Schematic diagram of an electrical MOST connection

Electrical Physical Bus Layer at 50 Mbit/s

As an alternative solution to optical systems, electrical transmission technologies
for MOST at a data rate of 50 Mbit/s are presently being developed. The motivation
for these endeavors is the desire to use existing electrical wiring technologies and tosave costs as compared to optical connections. Due to the lower electro-magnetic
compatibility, however, electrical data lines must be shielded. Otherwise, complex
driver circuits are required to meet the respective EMC demands. Both measures, in152 6: Physical Layer
turn, increase the system costs. The advantage of lower costs thus mainly depends
on the EMC requirements or the expense for EMC protection for “worst case” conditions.

Fig. 6.35: Eye diagram of an electrical
MOST signal with test mask

The physical bus layer for electrical transmission consists of a twisted-pair wire fortransmitting a differential signal in combination with suitable transmitters (or transformers) forming the interface between transmission medium and MOST Network
Interface Controller. Following the specification of the optical physical bus layer,
the specification points of the electrical physical bus layer are referred to as SP1E,
SP2E, SP3E and SP4E (see fig. 6.34).
The electrical specification parameters are basically predetermined by the signal
amplitude and the common mode voltage at a given load resistance and load capacitance. In addition, the electrical signals, as in the optical transmission technology,
must meet specified timing requirements (maximum pulse width distortion andphase variations). The electrical signals can be evaluated using an eye diagram.
Figure 6.35 shows an example of an eye diagram of an electrical signal and the pattern of a test mask. The electrical Physical Layer Specification [MOST ePhy] specifies a particular test mask and the parameters level 1, level 2 and the points A to Dof the trapezoid for all interfaces SP1E, SP2E, SP3E, and SP4E.

Fig. 6.36: Test circuit board with transmitter (left, source: SMSC Europe) and comparison
between shielded and unshielded electrical transmission media (right)

6.6 Alternative Transmission Media 153

Fig. 6.36 shows on the left an example of a test circuit board with a network controller (NIC), a MOST transformer and a connection socket for transmitters(TX+/TX-), receivers (RX+/RX-) and connections for the shielding. On the right,
different electrical transmission media are shown. Unshielded (unshielded twisted
pair, UTP) and shielded (shielded twisted pair, STP) wires can be used for connection. It depends on the desired line length, the EMC requirements and the transmission properties of the used transformers, which suitable medium is selected.

Fig. 6.37: Example of a coax cableand coax connector

Electrical Physical Bus Layer, based on Coax Line Drivers

A new approach for the electrical physical layer is to transmit the data over coax
cables in combination with coax line drivers. The idea is to replace the optoelectronic converter by a line driver and the use of standard connector and standard
coax cable that are well known and established in the automotive area. Fig. 6.37
shows an example of the cable and connector.

Fig. 6.38: Schematic of an electrical transmission line, indicating the compensation of thecable attenuation by an equalizer (source: Eqcologic)

154 6: Physical Layer
The main innovations of the system are the possibility to transmit in both directions
and to provide the power supply with the same cable. This gives MOST the opportunity to expand in other domains like in assistance systems where cameras have to
be integrated with small connectors due to limited installation space. To overcome
the bandwidth limitation of coax cables, it is essential to use an equalizer at the receiver side (see fig. 6.38). With an equalizer, the attenuation in the high frequency
domain of the cable is compensated. It is useful to regulate the gain by an adaptive
equalizer to compensate variations of the cable attenuation due to different cablequality and length. The physical layer working group is presently specifying thistechnology and will release both, an adapted basic specification and a new Electrical Physical Layer Sub-Specification. The system requirements concerning EMI
and immunity against different ground levels are also considered in this context.

155

7

Network and Fault Management

The MOST System comprises several master functionalities, each of which is only
allowed once in the system. They were already discussed in chapter 2. The following chapter goes into detail regarding the NetworkMaster – responsible for the network management. The NetworkMaster is the device which contains the function
block NetworkMaster. All other devices in the MOST network are referred to as
Slave devices or Slave components. The system is initialized by the Slave components exchanging information with the NetworkMaster during the start-up.

7.1

System Initialization

After wake-up, the NetworkMaster first of all builds up the communicative relations
to the Slave components via a system scan. After successful system initialization,
the communicative relations between the individual Slave components are established.

7.1.1

System QueryIf there is a stable lock, the NetworkMaster starts querying all nodes present about
their function blocks. It addresses each node position address. The Network and theTimingMaster reside in the same node. The TimingMaster is always the node zeroin the ring, i.e., it has the node position address 0x400 and the logical address
0x100.
The queried node informs the NetworkMaster about its stored logical node address
and the function blocks ready for communication:
0x01000x0401: NetBlock.01.FBlockIDs.Get ( )0x01010x0100: NetBlock.01.FBlockIDs.Status (FBlockIDList)

The NetworkMaster can read the information about the number of nodes in the system from the maximum position register (MPR) of its NIC. From the answer, theNetworkMaster can extract the following information about the queried node:

Node position and logical address of the node (more details in section 5.7)

Function blocks, which are supported by the node (FBlockIDList)

InstanceID of the respective function block156 7: Network and Fault Management
With the NetBlock (FBlockID 0x01), each MOST node has at least one FBlock;usually, several additional application FBlocks are implemented. The NetBlock is,
however, not transmitted in the FBlockIDList.

7.1.2

Central Registry

The NetworkMaster stores the information obtained by querying the node in theCentral Registry. It is filled with the logical addresses and the corresponding function blocks of all nodes; not, however, with the node position address. The Central
Registry is thus a logical map of the system and persists to the end of the systemrun. Figure 7.1 shows the query sequence for filling the Central Registry.
Node pos.
Addr.
0x400
0x401
0x402

CENTRAL REGISTRY
Log. Addr.
0x100
0x101
0x102

FBlockIDList
NetworkMaster
CD Changer
Amplifiernode pos. 0x400
log.
0x100

Network/Timing
Master0x100->0x401:NetBlock.01.FBlockIDs.Get()

0x101->0x100:NetBlock.01.FBlockIDs.Status(CD Changer)

Amplifiernode pos. 0x402
log.
0x102

CD
Changernode pos. 0x401
log.
0x101

Fig. 7.1: Illustration of the query sequence and filling of the Central Registry

As soon as valid System State OK is entered, the stored information is available forall participants in the ring. The NetworkMaster can then compare with a previously
stored registry and detect possible changes of the current network configuration. A
stored registry can possibly be a stored Central Registry of the last system run or aregistry pre-specified at the car assembly end of line test.
Network Status

The System State is distributed throughout the system by the NetworkMaster on the
protocol level by means of the message
NetworkMaster.01.Configuration.Status7.1 System Initialization 157

It indicates the current status of the system at any time and is sent as a broadcast
message to all nodes in the MOST system by the NetworkMaster.
System State OK

The Central Registry is valid, the NetworkMaster sends the message Configuration.Status(Ok). The reception of this status message means for all nodes that
the Central Registry can be queried. The Slave components can then establish theircommunicative relations with each other.
System State NotOK

If the current Central Registry does not match a stored registry, or if there is a system conflict, all communicative relations are aborted using the message
Configuration.Status(NotOK) by the NetworkMaster and a system scan is
initiated (see section 7.1.4).
The System State remains at NotOK until an OK message is sent off.
Configuration.Status (NewExt)

The notification of the function block signalizes the readiness of the underlying application to communicate. In some cases applications require more start-up time to
avoid confusion with notification. This is mostly the case with complex applications.
A node that wants to register additional new function blocks after the Configuration.Status(OK) was sent, must do so separately by way of the following message:
0x1xx0x100 NetBlock.xx.FBlockIDs.Status (FBlockIDList)

The NetworkMaster compares the newly registered function blocks to the ones
stored in its Central Registry. If new function blocks were added, this is broadcast
throughout the system via the message Configuration.Status(NewExt,
FBlockIDList).

This message can only be sent in the OK System State. The System State remains in
OK.
The case is different if there is an additional node participating in the system. The
NetworkMaster then queries all nodes about their function blocks again. It can thus
identify the new node and ascertain the node address. This is the big advantage ofdynamic address allocation (see section 7.1.4). If a new node is added in the middleof the ring, there is no system conflict if the new node has a free and unused logicaladdress.

158 7: Network and Fault Management
Configuration.Status (Invalid)

Apart from late registration of function blocks, a device can also deregister its application or function block. There might also be an unexpected problem within thedevice so that the entire node is no longer available in the system. For example, a
MOST device must close its electronic bypass for a certain period after an internal
reset.
If there is a change in the system to the effect that a node is no longer available (e.g.
due to a reset), the NetworkMaster starts querying all nodes in the system about
their function blocks. By comparing the result with the Central Registry, it can easily detect the dropped-out node. This is then broadcast throughout the system using
the message:
Configuration.Status (Invalid, FBlockIDList).

This message can only be sent in the OK System State. The System State remains inOK.
After function blocks have dropped out, the communication partners of the function
block concerned must update their Notification Matrix (see section 7.2) accordingly, i.e., they must cancel the dropped out function block. The same applies to theDecentral Registry, which is discussed in detail in section 7.2.
Node pos.
Addr.
0x400
0x402
0x401

CENTRAL REGISTRY
Log. Addr.
0x100
0x101
0x102

FBlockIDList
NetworkMaster
CD Changer
Amplifiernode pos. 0x400
log.
0x100

Network/Timing
MasterCD
Changernode pos. 0x402
log.
0x102

AmplifierNode pos. 0x401
log.
0x101

Fig. 7.2: Using the logical address for communicative relations. The Central Registry has
not changed compared to fig. 7.1.

7.1 System Initialization 159

7.1.3

Dynamic Addressing

The Central Registry only stores the logical, not the node position addresses. Bothtypes of addresses are decoupled from each other. The nodes get information via theCentral Registry about the addresses of function blocks that are found, in order toestablish direct communicative partnerships with each other. As only the logical address is used for the direct communication between the Slave nodes, there is no correlation with the actual node positions in the ring. If a node is added or dropped between the nodes of two communication partners, the logical address remains unchanged, whereas the node position address of all following nodes is changed. The
communicative relation thus remains unchanged.
If the NetworkMaster receives registrations from a Slave node of the address
0xFFFF during the system run (not only during the initialization of the system),
there is a system conflict. The NetworkMaster aborts all other actions and broadcasts Configuration.Status(NotOK). This causes all Slave nodes to discard
their stored logical address and to recalculate it according to
RxTxLog = 0x100 + Pos

7.1.4

Examples of System Starts

The following configuration is selected for the examples:

Node Posi- Logicaltion Address Address
Node 0Node 1
Node 2

0x400
0x401
0x402

0x100
0x101
0x102

Function Block

FBlock-ID

NetworkMaster
AudioDiskPlayer
AudioAmplifier

0x01
0x31
0x22

1. The Central Registry did not change after the latest system run. The AudioDisk
Player registers late.
0x01000x0401: NetBlock.01.FBlockIDs.Get ()0x01010x0100: NetBlock.01.FBlockIDs.Status ()0x01000x0402: NetBlock.02.FBlockIDs.Get ()0x01020x0100: NetBlock.02.FBlockIDs.Status (0x22,0x00)
0x01000x03C8: NetworkMaster.01.Configuration.Status (OK)0x01010x0100: NetBlock.01FBlockIDs.Status (0x31,0x00)
0x01000x03C8: NetworkMaster.01.Configuration.Status(NewExt,
0x22,0x00)

2. The AudioAmplifier was separated from the power supply for a considerable period of time. It lost its logical address.

160 7: Network and Fault Management
0x01000x0401: NetBlock.01.FBlockIDs.Get ()0x01010x0100: NetBlock.01.FBlockIDs.Status (0x31,0x00)
0x01000x0402: NetBlock.02.FBlockIDs.Get ()0xFFFF0x0100: NetBlock.02.FBlockIDs.Status (0x22,0x00)
0x01000x03C8: NetworkMaster.01.Configuration.Status (NotOK)
0x01000x0401: NetBlock.01.FBlockIDs.Get ()0x01010x0100: NetBlock.01.FBlockIDs.Status (0x31,0x00)
0x01000x0402: NetBlock.02.FBlockIDs.Get ()0x01020x0100: NetBlock.02.FBlockIDs.Status (0x22,0x00)
0x01000x03C8: NetworkMaster.01.Configuration.Status (OK)

7.2

Notification

Decentral Registry

If the NetworkMaster sends out a Configuration.Status(OK), establishment ofcommunication between the Slave devices is started off. This is usually effected byobtaining the logical address for each interesting function block from the components at the NetworkMaster.
0x01010x0100: NetworkMaster.01.CentralRegistry.Get(FBlockID, InstID)
0x01000x0101: NetworkMaster.01.CentralRegistry.Status(FBlockInfoList)
Node pos.
Addr.
0x400
0x401
0x402

CENTRAL REGISTRY
Log. Addr. FBlockIDList
0x100
0x101
0x102

NetworkMaster
CD Changer
Amplifiernode pos. 0x400
log.
0x100

Network/Timing
Master

AmplifierCD
Changernode pos. 0x401
log.
0x101

node pos. 0x402
log.
0x102

DECENTRAL REGISTRY

Log. Addr. FBlockIDList
0x102

AmplifierFig. 7.3: Configuration of the Decentral Registry from information of the Central Registry7.2 Notification 161

This information is stored in the Decentral Registry, as it is called, in the respective
slave. The Decentral Registry facilitates the finding of communication partners, as it
locally stores the result of each search. When accessing the same communication
partner again, the Central Registry does not need to be contacted again. It remembers the communication partners. The Decentral Registry and the Central Registry
may use the same syntax. Only the content is reduced to the information necessary
for the communication of the partner device. Figure 7.3 shows the sequence for theconfiguration of the Decentral Registry. With the help of the Decentral Registry thedevice can then communicate directly with the communication partner.
Notification Mechanism

In many cases devices must be informed of property changes in function blocks belonging to other devices. If this had to take place by a poll procedure, there would
be a heavy load on the bus. In order to prevent this, the mechanism of notification
was created. In the case of a property change, an event is sent to the devices that areentered in the Notification Matrix. The Notification Matrix is a table, which is implemented in the Network Service Layer II (section 9.3.3).
0x01010x0100: FBlock.InstID.Notification.Set (Control,
DeviceID, FktID1, FktID2,…)

DeviceID1
DeviceID2
DeviceID3
free
free

FktID1FktID2xxxx

FktID3x
x

ExampleA display unit (DeviceID 0x100) shall always display the current track number ofan AudioDiskPlayer. For this purpose, it sets notification for the function TrackPosition (FktID 0x202) of the AudioDiskPlayer and is automatically informed of
the new position at each track change. The following list shows the required control
messages. For further details, refer to the MOST Specification [MOST 3.0].
0x01000x0101: AudioDiskPlayer.01.Notification.Set (0x1,0x100, 0x202)
0x01010x0100: AudioDiskPlayer.01.TrackPosition.Status (01)0x01010x0100: AudioDiskPlayer.01.TrackPosition.Status (02):0x01010x0100: AudioDiskPlayer.01.TrackPosition.Status (05):162 7: Network and Fault Management
7.3

Power-Down

The shutdown of a MOST system is basically divided into two phases. In a preparatory phase, the system participants are notified of the shutdown. In the second
phase, the system is actually shut down and proceeds to sleep mode. The phases arereferred to as initiation and execution of the shutdown. As in the case of the startup, the PowerMaster takes on the control function for the power-down.
Initiation of the Shutdown

Initiation of a shutdown is usually effected by an external event, such as locking
the door of the vehicle. This trigger event is transmitted to the PowerMaster by wayof a MOST message. The PowerMaster then starts initiating the shutdown with thefollowing broadcast message:
0x01000x03C8: NetBlock.00.ShutDown.Start (Query)

The system participants can then prepare for the sleep mode. If a device requires
ongoing communication and is not yet ready to fall asleep, it informs the PowerMaster:
0x01010x0100: NetBlock.01.ShutDown.Result(Suspend)

The PowerMaster waits for a certain period of time tWaitSuspend and then repeats its
query.
Execution of the Shutdown

If the PowerMaster did not receive any objections from the devices within the time
tWaitSuspend, it executes the shutdown by way of the following message:
0x01000x03C8: NetBlock.00.ShutDown.Start (Execute)

After that, the PowerMaster switches off its modulated signal within the time t ShutdownWait (where t ShutdownWait = 2 sec usually). All subsequent nodes also switch off
their modulated signal, as soon as they have not received a light from the RX input.

7.4

Fault Types

This section differentiates in two kinds of faults: Network faults and device faults.

7.4 Fault Types 163

7.4.1

Network Faults

Ring BreakNormally, a device in a MOST system is woken by the reception of a modulated
signal at its RX input. As a consequence, it transmits a signal on its TX output. If a
TimingMaster transmits a signal on its TX output, it usually receives a signal on its
RX input within a defined time if all TimingSlaves are connected in a ring topology. However, it is possible that the ring cannot be locked because of an inaccurately connected component, a defect component or a broken cable. In this case, astart-up for normal operation is not possible anymore.
Sudden Signal Off

If a device loses the signal at its RX input abruptly (i.e., without a previously initiated shutdown procedure), it automatically switches to TimingMaster mode. Afterwards, it sets the Shutdown Flag in the administrative area of the transmitted MOST
frames in order to inform the other nodes about the coming shutdown. After transmitting this signal within the time interval tSSO_ShutDown, it turns off the transmission
and stores the cause of the fault. Because the other nodes have detected the Shutdown Flag, they do not store a fault event before also shutting down. Hence, a Sudden Signal Off leads to a shutdown of the whole MOST network.
Unlock and Critical Unlock

The loss of synchronization between the system clock of the TimingMaster and a
TimingSlave device is referred to as unlock. An unlock can have many reasons,such as a faulty RX or TX component or insufficient signal intensity for detecting
the system clock. A differentiation is made between short and critical unlocks. A
short unlock is defined by the loss of synchronization for less than tUnlock (usuallyless than 100 ms, typically 70 ms). A short unlock is compensated by the TimingMaster regenerating the signal.
There is a critical unlock if the loss of synchronization takes longer than tUnlock. According to the behavior described in the paragraph “Sudden Signal Off”, the affected device automatically switches to TimingMaster mode, transmits MOST
frames with an appropriate Shutdown Flag, stores the fault reason, and finally shuts
down.
Coding Errors

Coding errors have their reason in a violation of the coding scheme, e.g., due tohigh signal attenuation based on a deformed cable. Because the nodes cannot
decode the received data, there is either delayed communication with many164 7: Network and Fault Management
retransmissions, or even data loss. A massive occurrence of Coding errors can leadto an Unlock, a Critical Unlock or a Sudden Signal Off.

7.4.2
tions

Device Faults caused by Temperature and Voltage Viola-

This section considers faults that occur if MOST devices are shut down to protect
them against malfunctions or permanent damage caused by temperature and voltage
violations.
Of course, in a system further device faults can occur. However, faults caused bytemperature and voltage violations are of particular importance for a MOST network because the sudden shut down of a MOST device leads to a Sudden Signal
Off event. MOST provides special mechanisms that allow differentiating in OverTemperature, Undervoltage and Overvoltage faults and special handling of them.
Over-Temperature

High demands are made on the vehicular devices as far as the temperature range isconcerned. Due to physical circumstances, the required operational temperaturecannot always be observed. Each participant in the ring therefore has the possibility
to initiate a temperature-related shutdown to protect all components. If a device exceeds its specified temperature Shutdown, it broadcasts the message NetBlock.ShutDown.Result (Temperature Shutdown). If the critical temperature Critical is reached, the device initiates an immediate shutdown by simply
switching the modulated signal off. Because a PowerMaster has previously received
the temperature shutdown request, it waits a certain time for cooling down and afterwards it wakes up the system again.
In addition, a further kind of the temperature shutdown can be used: if the temperature AppOff is reached, it is optional to shut down only a part of the application (forexample an overheated drive). The remaining functionality can still be used. The
corresponding FBlock must be unregistered from the Central Registry.
Undervoltage

Undervoltage in the vehicle power system does not usually affect all devices at thesame time and to the same extent. There are thus two different undervoltage thresholds:


Critical Voltage UCritical: This undervoltage level is defined such that network
communication is still ensured, but not the complete function of an application.
The Network Service remains in the Normal Operation mode. Data is not sent
over streaming connections anymore. It means, a source must route zeros and a7.4 Fault Types 165

sink must secure its output signals. The Mute property remains unchanged.
When the normal voltage has been reached, the data can be sent again.


Low Voltage ULow: This undervoltage level is defined such that communicationof the network interfaces can no longer be ensured. If ULow is reached, the device switches off the modulated signal and switches to DevicePowerOff mode.
The device stays in DevicePowerOff mode, even if the supply voltage recovers.
It is awakened either by “modulated signal on” at its input or by the demand forcommunication from its own application. It changes to mode DeviceNormalOperation via the standard initialization process.

Overvoltage or Super voltage

If the voltage exceeds super voltage (USuper), the device has to move in a safe operation state, which must be defined for each device individually. A typical value for
USuper is 16V.

166

167

8

Network Diagnostics

In this chapter, the handling of diagnostics in a MOST system is described. It considers mechanisms for identifying network faults and for localizing their origins in
the network. These mechanisms are important especially in the automotive environment because they reduce costs during system production and maintenance. Finally, the chapter considers faults that occur in MOST devices. Using a special
communication protocol (Diagnostics Adaptation Protocol, DAP) a diagnostics test
tool is able to read out the fault memories of MOST devices.

8.1

Network Fault Detection

MOST is able to handle several network fault types.

8.1.1

Ring Break Diagnosis

As a result of the ring break diagnosis (RBD), every device stores its node position
in relation to a ring break. This is possible if the device behind the ring break becomes the TimingMaster. It transmits a signal that contains the node position. Each
TimingSlave increments the received node position value. If no ring break is detected, the original TimingMaster begins normal operation.
At first, an external trigger is applied to the device for starting the RBD. The trigger
event is system specific. For instance, it is possible that a system test on the Electrical Control Line (see also section 8.1.4) executes the RBD.
Figure 8.1 shows exemplarily the RBD procedure.
The original TimingMaster of the example network is Node 0. Node 1, Node 2, andNode 3 originally act as TimingSlaves. There is a ring break between Node 1 andNode 2. At the beginning, each TimingSlave waits for activity on its RX input. A
node switches from TimingSlave mode to TimingMaster mode if it has not detectedany activity during the time interval tDiag_Signal. Therefore, Node 2 and Node 3 act as
TimingMaster after tDiag_Signal. Afterwards, Node 3 receives a signal from Node 2.
Therefore, Node 3 switches immediately back to the TimingSlave mode. After thetime interval T1 the original TimingMaster, Node 0, evaluates its RX input. Because it detects a signal but no stable lock, it recognizes that there is a second TimingMaster in front of it. Therefore, it switches from TimingMaster mode to TimingSlave mode. This procedure leads to an open chain beginning with a TimingMaster (Node 2) and continuing with all other nodes as TimingSlaves (Node 3,
Node 0, and Node 1). The TimingMaster Node 2 transmits a signal containing the

168 8: Network Diagnostics
node position 0. Node 3 receives this signal and increments the node position. It
stores node position 1, and transmits a signal containing this new node position
value. The node position handling is continued by the following TimingSlaves.
Nodeposition

Activation trigger
Node
0

Node
1

Node
2

Node
3

0

M

M

M

S

Receiving no signal
Sending own signal

Receiving signal,
but no stable lock
Sending own signal

Receiving signal,
but no stable lock
Sending own signal

Receiving signal
Sending signal

S

S

S

S

Receiving signal
Sending signal

Receiving signal
Sending signal

Receiving signal
Sending signal

Receiving signal
Sending signal

S

M

M

M

Receiving no signal
Sending no signal

Receiving no signal
Sending own signal

Receiving no signal
Sending own signal

Receiving no signal
Sending own signal

S

M

S

S

Receiving no signal
Sending no signal

Receiving signal,
but no stable lock
Sending own signal

Receiving signal
Sending signal

Receiving signal
Sending signal

tDiag_Signal

2

3

0

1

time
T1

Fig. 8.1: Localization of the ring break

Finally, it is possible that the RBD result is delivered to a dedicated device. This
last step is optional and depends on the system solution.

8.1.2

Sudden Signal Off/Critical Unlock Detection

This function is new in the MOST Specification Rev. 3.0. If a node causes a Sudden
Signal Off (SSO) or a Critical Unlock (CU) event in NetInterface Normal Operationmode, the succeeding node cannot receive a valid signal anymore. As a consequence, this succeeding node switches to TimingMaster mode, sets the Shutdown
Flag in the administrative area of the transmitted MOST frames, stores the fault
cause and finally shuts down as already described in section 7.1.
The original TimingMaster cannot detect the Shutdown Flag. Therefore, it also detects an SSO or a CU fault and stores it. This must be considered in an appropriate
fault evaluation.

8.1 Network Fault Detection 169

An evaluating device can use the MOST property NetBlock.ShutDownReason tocollect the locally stored fault information. When it has gathered the informationfrom all nodes, it broadcasts NetBlock.ShutDownReason.Set(0x00). Afterwards, all nodes delete the stored shutdown reason.
An evaluating device must apply an evaluation algorithm in order to detect the origin of the fault because it is possible that more than one node reports a fault:

If a TimingSlave reports an SSO, an SSO fault is definitely in front of the TimingSlave. Because of fault propagation, it is possible that other nodes report
CUs. The evaluation algorithm should ignore them.



If the TimingMaster reports an SSO and no TimingSlave reports an SSO or
CU, the SSO fault is definitely in front of the TimingMaster.

In principle, there could be more than one CU report because of fault propagation in the MOST network. If no additional SSO is reported, the initial CU is in
front of the first TimingSlave that has reported the CU.

If at least one TimingSlave reports an SSO or CU, the situation in front of theTimingMaster is unclear. Therefore, the evaluation algorithm should ignore thereport of the TimingMaster.

8.1.3

Localizing the Origin of Coding Errors

The Network Service of each MOST node is able to count coding errors. They areusually not counted during start-up or shutdown of the network but while the system is normally operating. Furthermore, a node does not count coding errors if
unlocks, CUs, or SSOs occur. A node counts at maximum one coding error within asystem specific time interval.
A dedicated node can use the MOST property Diagnosis.CodingError to readthe coding error counter of each node. It detects the origin of a coding error fault directly in front of the node with the lowest node position that reports a number ofcoding errors that is greater than a system specific threshold. The evaluating node
should ignore the coding error reports of succeeding nodes to compensate for fault
propagation.

8.1.4

Electrical Control LineSome car manufacturers have decided to introduce the ECL (Electrical ControlLine) in addition to the MOST network in order to be able to detect network faults
even if the faulty MOST network prevents any communication. This new optionalfeature is based on MOST Specification Rev. 3.0 and described in a separate

170 8: Network Diagnostics
document [ECL]. The ECL connects the MOST devices by additional cabling.
These connected devices are able to exchange information in an electrical, serial
and digital way via the ECL.

voltage
supplyvoltage

E: Ring break diagnosis on
MOST network
G: Eachparticipant
waits for its
time slot
C: Initiator triggers
start of system test

000000ground
A: Initiator triggers
system test start impulse

I: Participant declares its
RBD result

B: Device
D: Initiator triggers F: Initiator triggers start
start-up timeof response sequenceRBD(e.g., 4000 ms)time
H: Participant
declaresits activity

Fig. 8.2: Sequence of a system test

The idea is that a dedicated device uses the ECL in order to initiate the execution ofa so-called system test. A system test can include ring break diagnosis, SSO/CU
fault origin detection, or coding error counting. After finishing a system test, eachparticipating device sends its test result back to the initiator via the ECL.
Figure 8.2 depicts exemplarily the whole sequence of a system test.
In step A, the initiator device transmits a system test start impulse to all participating devices by pulling the voltage of the ECL down to ground for 200 ms. During
step B, there is no activity on the ECL. All participating devices have time to startup. In step C, the initiator synchronizes all participating devices by transmitting animpulse that identifies the start of the system test. To this end, it pulls the voltage
down to ground for 250 ms. At step D, the initiator triggers a system test by sending
an appropriate parameter sequence. Let the value “0” be defined by pulling voltage
to ground for 50 ms, and let value “1” be defined by leaving the ECL at supply
voltage for 50 ms, then the parameter sequence

“0-0-0-0-0-0”defines an RBD test. If a participant detects a stable lock, it sends“0” in its result time slot at step I; else, it sends “1”.



“0-1-0-0-0-0” defines a coding errors test. If the detected number of coding errors exceeds a system specific threshold, the participant sends “0” at step I;
else, it sends “1”.



“1-0-0-0-0-0” defines an alive test. As shown in figure 8.2, there is a time slot
at step H for each participant to declare its general activity. For each systemtest, an active participant sends “0” in this time slot. In case of an alive test, theparticipant sends no further result at step I. An alive test can be applied forchecking the general availability of the devices.

8.2 Device Fault Diagnosis 171

“1-1-0-0-0-0” defines an SSO/CU test. If a participant does not detect an SSO
or CU during the test, it sends “0” at step I; else, it sends “1”.

While executing the system test, all devices leave the ECL at supply voltage (seestep E). At step F, the initiator triggers the start of the response sequence by pullingthe voltage down to ground for 100 ms. This activity synchronizes all participating
devices. Afterwards, each participant must wait for its time slot (step G). Each device has been statically assigned its own time slot. This assignment is independentof the MOST ring position. As already mentioned, a participant responds at step H
and step I.

8.2

Device Fault Diagnosis

This section introduces the Diagnostic Adaptation Protocol (DAP). It adapts a
communication protocol for vehicular diagnosis to the actual communication protocols of MOST. This function is new in the MOST Specification Rev. 3.0; its use isoptional and is described in a separate document [DPA].
The basic concept for vehicle diagnosis is this: Diagnostic services reside in devices
in vehicles. A diagnostic test tool acts as client by requesting these services. Thisway, a diagnostic test tool in a workshop can read, e.g., the trouble code of each device. Every fault occurrence in a device leads to a new trouble code entry in its fault
memory. A trouble code entails an appropriate instruction for an action by theworkshop staff.
Protocol stacks used in caseof physical addressing
UDS

…

DAP

UDS

…

Protocol stacks used in caseof functional addressing

UDS

…

UDS

…

UDS

…

DAP

DAP

DAP

DAP

TCP

AMS

AMS

UDP

IP

CMS

CMS

IP

MOST
Packet Data
Channel(Ethernet
over MOST)

MOST
Control
ChannelMOST
Control
Channel

MOST
Packet Data
Channel(Ethernet
over MOST)

MHP

MOST
Packet Data
Channel(MOST High)

Fig. 8.3: Protocol Stacks

For realizing the client/server communication, many protocols can be applied. For
instance, Unified Diagnostic Services (UDS) [ISO 14229] is often used for the purpose of vehicular diagnosis.

172 8: Network Diagnostics
Figure 8.3 shows the communication protocol stacks that realize a diagnostic message exchange on MOST using DAP.
Physical addressing means that the client sends requests to exactly one server. It is
possible that after service execution the server sends back a final response. For instance, a response can contain the requested diagnostic trouble code of a device.
Furthermore, the server may send back response pending messages while executing
a diagnostic service. Physically addressed requests and their corresponding responses can be transported via the MOST Packet Data Channel using MHP or TCP,
or via the MOST Control Channel using AMS.
Functional addressing means that the client sends requests to many distributed servers. Multicast or broadcast mechanisms are the obvious means of transporting theserequests. A server has the possibility to send back response pending messages or a
final response message. Functionally addressed requests can be transported via the
MOST Packet Data Channel using UDP, or via the MOST Control Channel using
AMS. The usage of either blocking or unblocking broadcast as specified in the
MOST Specification [MOST 3.0] is possible.

Byte Order

Data Field

Len(Byte)

1
2–5

VersionPayloadLengthType of Service

1
4

Version of DAP Header: 0x01
n1

System Integrator Part
Source Address
Payload2

System Integrator specific: 0x00
UDS: 0x01
KWP2000: 0x02
Reserved for future use: 0x03 – 0xBF
System Integrator specific: 0xC0 – 0xFF
System Integrator specific: 0x0000 – 0xFFFE
Default: 0xFFFF
e.g., Diagnostic test tool address
Not used: 0xFFFF

6

7-8
9 – 1011 –(10+n)

2n

Table 8.1: Structure of a DAP packet

Value8.2 Device Fault Diagnosis 173

The first data field identifies the version of the DAP header, which currently is
0x01.
Afterwards there is the data field “Payload Length”. For stream-oriented TCP, thisfield can be used for reassembling a diagnostic message from the byte stream. Furthermore, if the UDS message size is greater than the maximum MHP packet size,
this field is needed for segmentation and reassembly, too.
The next data field “Type of Service” selects the application protocol. The payloadof a received DAP packet can be assigned to UDS, or to another application protocol (e.g., KWP2000).
The data field “System Integrator Part” is set to 0xFFFF by default. It can be usedby the System Integrator, e.g., in order to work with sequence numbers if needed.
The data field “Source Address” identifies the diagnostic test tool that has sent a request. A server device has to copy the data of this field from a diagnostic request to
the corresponding diagnostic response. Thus, the transport of a diagnostic responseto the original diagnostic test tool is possible even when there is more than one diagnostic test tool and if the response must be transported via more than one network.
Finally, the data field “Payload” contains the diagnostic message that is processedby UDS, or by another application protocol (e.g., KWP2000).

174

175

9
9.1

Network Service
Overview

The Network Service represents the standard protocol stack for MOST. The commonly used term MOST NetServices is a trade name of SMSC Corporation, where
the MOST NetServices have to be licensed. The MOST Specification uses the term
Network Service, however, as a term which is independent of a product.
As shown in figure 9.1, the Network Service is based on the Network Interface
Controller (NIC) or the Intelligent Network Interface Controller (INIC) and provides a programming interface for the application which basically consists of thefunction blocks. It comprises modules for transferring packet data in the Packet
Data Channel and modules for controlling the network via the Control Channel, i.e.,
it contains mechanisms and routines for operating and managing the network and it
ensures dynamic behavior of the network. The Network Service is implemented on
the External Host Controller (EHC). Control of the Streaming Data Channels is alsopart of the Network Service; the transmission of streaming data, however, is not.

Network Interface Controller
Network Services
Low Level

Fig. 9.1: Basic structure of the MOST NetServices

NIC
or
INIC

176 9: Network Service
9.2

MOST NetServices

The MOST NetServices are a standard implementation of the Network Service provided by SMSC. They are tuned to the Network Interface Controllers (NIC and
INIC).
The MOST NetServices are divided into the Basic Layer (Layer I) and the Application Socket (Layer II) and can contain additional modules, such as the MOST High
Protocol (see section 5.8).
OSI Layer

Application

Presentation

Session
NetServices
Layer I 1.x
Basic Level

Transport
Network

Data Link

Intelligent
Network Interface
Controller
Network Interface
Controller

Physical

NIC

INIC

Fig. 9.2: Model of the
MOST NetServices

The MOST NetServices are written in ANSI-C and can be used directly for portingon the different processor platforms (EHC). SMSC offers 4 license types:


Evaluation licenseSystem licenseProduct licenseTool license

9.3 Modules of the MOST NetServices 177

9.2.1

Models of MOST NetServices

The NIC and the INIC have their own versions of the MOST NetServices Layer I(version 1.x for NIC; versions 2.x and 3.x for INIC), since the INIC covers the basic
functions of Layer I itself and the MOST NetServices only have to provide an interface between Layer I and II. The MOST NetServices Layer II 1.x and 2.x/3.x only
differ in the modules, whose functionality is covered by the INIC.

9.2.2

Dependencies on MOST Specification Baseline

The MOST NetServices versions 1.x and 2.x have been designed according to
MOST Specification Rev2.x. Version 1.x is available for MOST25 only, while version 2.x is suitable for MOST25 and MOST50.
Version 3.x has been designed according to MOST Specification Rev. 3.x and isavailable for MOST50 and MOST150.

9.3

Modules of the MOST NetServices

9.3.1

Layer I Version 1.x

The MOST NetServices Layer I version 1.x have been designed for the NIC. The
I²C bus, the SPI or a parallel interface are available as interfaces. The software interface of the NIC consists of a set of registers, which can be read and written by
the microcontroller. The set of registers is referred to as a register wall.
In the following, the modules of Layer I are introduced.
Figure 9.3 gives an overview of the modules of Layer I 1.x.
MOST NetServices Kernel (MNS)

MOST NetServices Kernel (MNS) is the central entry point for all services ofLayer I. It initializes all trigger and call-back functions.
MOST Supervisor (MSV)The MOST Supervisor (MSV) provides a finite state machine for the network management. The following functions are covered:

NIC initialization

Determination, whether the device is TimingMaster or TimingSlave

Configuration of the Source Port

178 9: Network ServiceNetwork start-up and shutdownPower Management



Error diagnosis and error message generation

Self test

Different Source Port configurations are supported.
Level I API

Register Wall
Network Interface Controller

Fig. 9.3: MOST NetServices Layer I version 1.x

Control Message Service (CMS)The Control Message Service (CMS) sends and receives the control messages
which are transmitted on the Control Channel. The service comprises the following
functions:

Initialization

Control Message reception serviceControl Message sending serviceMessage bufferingError handling and error message

Asynchronous Data Transmission Service (ADS)The Asynchronous Data Service (ADS) is responsible for sending and receiving
packet data on the Packet Data Channel. The service comprises the following functions:

Initialization

Buffered sending of packet data

9.3 Modules of the MOST NetServices 179

Buffered receiving of packet data

Error handling and error message

Application Message Service (AMS)The Application Message Service (AMS) is based on the Control Message Service
and provides a transmission protocol for segmentation of longer application messages which are transmitted on the Control Channel. It segments the messages into
17-byte blocks in the sender and reassembles the message from these blocks in thereceiver. The service provides the following functions:

Initialization

Sending application messages

Receiving application messages



Buffering messages

Error handling and error message

Synchronous Connection Service (SCS)The Synchronous Connection Service (SCS) controls the Routing Engine (RE) integrated into the NIC. It provides the necessary functions for allocating and releasing the Streaming Data Channels and for configurating the streaming data sourceand sink. The following are the functions in detail:

Channel Allocation

Allocation and Routing

De-Allocation

De-Allocation and Routing-DisconnectSource-ConnectSource-DisconnectSink-ConnectSink-DisconnectDetect-Channel by label

MOST Transceiver Control Service (MCS)The Transceiver Control Service (MCS) enables the application-specific initialization of the NIC. By means of this service, hardware-relevant parameters can be set.
The following functions are available:

Setting of the address registers in the NIC

Access to important NIC registers (via the Register Access API)

180 9: Network ServiceSetting of the RMCK frequency

TimingMaster functions (selection of the frequency source, setting of theBoundary Descriptor)

Further information can be found in the MOST Specification [MOST 3.0], in the
Basic Services (Layer I) Programmer´s Library documentation [MNS L1 1.x] andin the MOST NetServices Layer 1 Example [MNS L1 Exa].

9.3.2

Layer I Versions 2.x and 3.x

The MOST NetServices versions 2.x and 3.x of Layer I are based on the INIC,
which integrates the kernel functionality of Layer I (administration of the network
status, transceiver check, driver for message reception and dispatch, control of the
Routing Engine). The MOST NetServices thus only have to provide buffers for data
handling and the API known from version 1.x. The modules of the NetServices arealso referred to as Wrappers. Access to the INIC is no longer effected via a register
wall, but via an integrated FBlock based on the messages. This different type of access is, however, abstracted by the wrapper modules. The Layer I API remains
mostly unchanged.
Level I API

MOST NetService MiniKernelIntelligent Network Interface Controller

Fig. 9.4: MOST NetServices Layer I version 2.x

9.3 Modules of the MOST NetServices 181

The interface for MOST Control Messages, as well as for administrative communication between the NetServices and INIC is the Control Port, which is physicallyaddressed via I²C, or the MediaLB Port.
A further interface is used to provide access to the Packet Data Channel. This interface can be physically addressed via I²C, MediaLB, or in version 3.x also via SPI.
Figure 9.4 shows the structure of the MOST NetServices version 2.x.
Figure 9.5 illustrates the structure of version 3.x. Auxiliary to the new SPI interface,
the Control Message Service (wCMS) was eliminated and the MOST Debug Message Module (MDM) was newly introduced.
MOST NetServices Kernel (MNS)

MOST NetServices Kernel (MNS) is, as in version 1.x, the central entry point for
all services of Layer I. It initializes all trigger and callback functions.
Virtual MOST Supervisor (vMSV)The Virtual MOST Supervisor (vMSV) provides the user with a mapping of the actual supervisor implemented in the INIC. The functionality is similar to version 1.x.
In comparison to version 2.x, version 3.x provides enhanced network diagnostics
functions.
Level I API

MOST NetService MiniKernelIntelligent Network Interface Controller

Fig. 9.5: MOST NetServices Layer I version 3.x

182 9: Network Service
Wrapper Modules

The Wrapper Modules Control Message Service Wrapper (wCMS), Application
Message Service Wrapper (wAMS), MOST Processor Control Service Wrapper(wMCS) and Asynchronous Data Service Wrapper (wADS) basically map the APIof version 1.x onto the functions of the INIC. Only the API of the Socket Connection Manager Wrapper (wSCM) deviates considerably from the SCS-API because
the administration of the Streaming Channels now runs directly via sockets and nolonger via the direct programming of the Routing Engine.
The Control Message Service Wrapper (wCMS) applies for version 2.x only. In
version 3.x it is substituted by the Application Message Service Wrapper (wAMS).
In comparison to version 2.x, the Socket Connection Manager Wrapper (wSCM) of
version 3.x also provides interfaces and configurations to access the Isochronous
Streaming Data Channel and new interfaces (e.g. TSI - Transport Stream Interface
for video applications).
Data Handling to the INIC

The interface between the INIC and the MOST NetServices uses a Port Message
Protocol. The modules Message Interface Service (MIS), Message Buffer Management (MBM) and Port Message Service (PMS) control this protocol, buffer themessages and supervise the different FIFOs in the INIC.
Further information can be found in the MOST NetServices Layer I –Wrapper for
INIC – User Manual/Specification [MNS L1 2.x or MNS L1 3.x].
MOST Debug Message Module (MDM)

MOST Debug Messages are messages that are reported on the MOST Control
Channel, suitable to signal any device or system related debug information. Suchmessages are not received by any other device, but they can be recorded by System
Analysis tools. The MOST Debug Message Module (MDM) controls the protocol
and provides transmission services for such events. It is available in version 3.x
only.

9.3 Modules of the MOST NetServices 183
Level II API

Network Interface Controller
Fig. 9.6: MOST NetServices Layer II

9.3.3

Layer II Versions 1.x, 2.x and 3.x

The MOST NetServices Layer II builds on MOST NetServices Layer I. They provide
the API for the application-specific function blocks. The system function blocks,
such as the NetBlock, are, however, part of the MOST NetServices. Since the implementation of the function block EnhancedTestability (ET) is applicationspecific; the MOST NetServices only contain a “skeleton”.
The modules which differ in version 1.x and 2.x will be referred to in the corresponding sections. Figure 9.6 shows the structure of Layer II.
MOST NetServices Kernel Layer II (MNS2)

As in Layer I, MOST NetServices Kernel (MNS2) is the central entry point for all
services of Layer II. It initializes all trigger and callback functions.
MOST Supervisor Layer II (MSV2)

MOST Supervisor Layer II (MSV2) also provides a finite state machine for managing the network state on the application level (e.g., communication permitted/not
permitted). The following functions are implemented:
Address initialization

Configuration on the application level after the Init Ready eventIn the NetworkSlave: Initialization of the Decentral Registry

In the NetworkMaster: Network Change Event (NCE) supervision184 9: Network Service
FBlockID

Pointer on InstID; stored in
RAM

NetBlock
FBlock 1
FBlock 2…
FBlock n
FBlock Shadow 1
FBlock Shadow 2…
FBlock Shadow m

0&NetBlock.pFBlockIDs.InstID[0]&NetBlock.pFBlockIDs.InstID[1]Pointer on Function
Table; stored in ROM&Func_NetBlock&Func_FBlock1&Func_FBlock2&NetBlock.pFBlockIDs.InstID[n-1] &Func_FBlockn&InstIDShadow[0]&Func_FBlockShadow1&InstIDShadow[1]&Func_FBlockShadow2&InstIDShadow[m-1]&Func_FBlockShadowm

Table 9.1: Table of the available FBlocks and FBlock Shadowsn – number of FBlocks
m – number of FBlock Shadows (source: [MNS L2])

Command Interpreter (CMD)

The Command Interpreter Module is used for table-controlled decoding of received
control messages and for automatically calling the handler functions of the FBlocks
defined by the user.
The decoding table contains all implemented FBlocks and FBlock Shadows. It basically has the structure shown in table 9.1 and can easily be extended.
The table of the available FBlocks and the function tables can be stored in ROM.
As the instance ID can be changed during runtime, the table containing these IDs
must be stored in RAM (second column). During initialization, it is filled with default values. The third column contains the entry address of the related function.
Notification Service (NTFS)

The Notification Service (NTFS) is used for automatically sending status messages
to other devices, when the properties of an implemented FBlock change. Thismechanism was already introduced in section 4.2.2.
Table 9.2 shows the Notification Matrix of an FBlock. The matrix must be available
for each FBlock supporting the Notification Service.
FBlock x

Property 0

Property 1

Property 2

Flagfield 0
Entry 0.1

Flagfield 1
Entry 1.1

Flagfield 2
Entry 2.1

Property (n-1)…
…

Flagfield (n-1)
Entry (n-1).1

9.3 Modules of the MOST NetServices 185
FBlock x

Property 0

Property 1

Property 2

Entry 0.2
Entry 0.3
Entry 0.4…
Entry 0.m

Entry 1.2
Entry 1.3
Entry 1.4…
Entry 1.m

Entry 2.2
Entry 2.3
Entry 2.4…
Entry 2.m

Property (n-1)
…
…
…
…
…

Entry (n-1).2
Entry (n-1).3
Entry (n-1).4
Entry (n-1).m

Table 9.2: Notification Matrix of the FBlock x (source: [MNS L2])n – number of properties of the FBlock which support the Notification Servicem – max. number of devices able to subscribe to the property

The term Entry in the table is an index in the Device Table which stores the logicalor group addresses of the devices that have subscribed to properties.
Address Handler (AH)

The Address Handler (AH) is based on a state machine. It transforms symbolic addresses into memory locations and manages the Decentral Registry in the Slave.
Similar to other modules of Layer II, it closely cooperates with the Application
Message Service (AMS).
The Controller does not necessarily have to know which device implements an
FBlock. It suffices if the FBlockID and the InstID are known. The wildcard 0xFFFF
is entered into the target address field of the control message. If the Address Handler (AH) receives a message with this wildcard, it first searches the FBlockID withthe related InstID in the Decentral Registry in the standard configuration, as isshown in figure 9.7. If it finds the FBlock, it replaces the target address field withthe real target address. If the search fails, it inquires, by means of the NetworkMaster Shadow Module, about the FBlock at the Central Registry located in the NetworkMaster. A further mode, where the MOST NetServices can inquire about thedesired instance directly at each device in the ring is not defined in the MOST
Specification and thus is neither used, nor supported by version 3.x.
Send a message using theApplication Message Service

Target Address != 0xFFFF

Complete
Transmission

Target Address == 0xFFFF

First Searching Process(local Decentral Registry)
Search failed

Second Searching Process(Central Registry, but not local)
Search failed
Report Error

Searchsuccessful

Searchsuccessful

Fig. 9.7: Search procedure of the
Address Handler (source: [MNS
L2])

186 9: Network Service
Figure 9.8 shows an example of address handling. Track 10 in the CD changer(CDC) is to be selected via the HMI. The CD changer application is represented on
the device with the FBlock CD (Instance-ID: 1). To change the track, the HMI
sends the control message CD.1.Track.Set(10). The HMI application gives thecommand 0xFFFF.CD.1.Track.Set(10) to the Address Handler, which replaces the wildcard 0xFFFF with the target address of the CD changer, according to
the procedure explained above. The MOST Network Interface Controller automatically adds the source address and sends the message to the CD changer. The MOST
Network Interface Controller of the CD changer sends the message on to the MOSTNetServices. The CMD module calls the function for changing the property Track in
the FBlock CD.
Figure 9.8 shows the general syntax of the control message on its way from thesender to the receiver.
NetworkMaster Shadow Module

The NetworkMaster Shadow Module provides a copy of the properties of the
FBlock NetworkMaster. It reacts to status and result messages and is usually implemented on all devices, except the NetworkMaster. The basic functions are:
1. Managing the property NetworkMaster.Configuration during the initializing procedure.
2. Managing the property NetworkMaster.CentralRegistry during the address
search procedure of the Address Handler.
CDC (Slave)

HMI (Controller)

Application
Application

CD.1.Track.Set(10)FBlockID.InstID.FktID.OPType(Parameters)

FBlock CD
InstID: 1????.FBlockID.InstID.FktID.OPType(Parameters)

FFFF.CD.1.Track.Set(10)DeviceID1.FBlockID.InstID.FktID.OPType(Parameters)

AH

HMI.CD.1.Track.Status(10)NetServices

NetServices
NMWS

CMD
AMS

AMS
DeviceID2.FBlockID.InstID.FktID.OPType(Parameters)

CDC.CD.1.Track.Set(10)MOST Network
InterfaceController

Device 1

HMI.CD.1.Track.Set(10)DeviceID1.FBlockID.InstID.FktID.OPType(Parameters)
DeviceID1.DeviceID2.FBlockID.InstID.FktID.OPType(Parameters)

HMI.CDC.CD.1.Track.Set(10)MOST Network
InterfaceController

Device 2

Fig. 9.8: Example of address handling (according to [MOST 2.5] and [MOST 3.0])

9.4 Integration of the MOST NetServices onto the Target Platform 187
NetBlock (NB)

The NetBlock (NB) is a system FBlock, which must be implemented on all devices.
It is thus part of the MOST NetServices Layer II. It was already introduced in section 4.3.4.
Due to the fact that a minimum NetBlock (NBMIN) is already integrated in the
INIC, only the NetBlock EHC (NBEHC) of the NetBlock in Layer II version 2.x or
3.x is implemented (see section 10.4.2).
FBlock EnhancedTestability (ET)The FBlock EnhancedTestability (ET) is a system FBlock as well and is also described in section 4.3.4.

9.4

Integration of the MOST NetServices onto the Target Platform

The MOST NetServices were written in ANSI-C without using any standard libraries and can thus very easily be ported onto the target platform. The configuration
and adaptation for the hardware and software platform used is effected via compiler
switches in the header files adjust*.h. This enables a good scaling onto the processor architecture. The MOST NetServices can be implemented on an 8-bit microcontroller with only a few kbytes RAM in a Main Loop Architecture, or also on a 32bit microcontroller with adequate multitasking software systems, such as QNX,WinCE, or Linux.
The Low Level Driver (LLD) shown in Figures 9.3 and 9.4 must be implemented
by the user. The LLD is used for abstraction of the hardware with regard to the
MOST NetServices. The two System-On-Chip Controllers OS8805 and OS88558
are an exception. In this case, the MOST NIC and the Host Controller are integrated
on one chip. The MOST NetServices only need to be configured by the user.

9.4.1

Callback Functions

The largest part of the MOST NetServices provides callback functions for status anderror messages. These functions are made available to the programmer and arecalled by the MOST NetServices if a specific event or an error has occurred.
The callback functions are characterized in the MOST NetServices documentationby the key word [Callback].
[Callback]declaration of function;

188 9: Network Service
The MOST NetServices offer different types of callback functions for the various
versions.
MOST NetServices Layer I 1.x

The MOST NetServices Layer I 1.x specify callback functions of type A and B:Even though the type A functions must be defined by the programmer, thefunction body can remain empty if the event which calls the function is not
relevant for the application.

Type B functions, however, must always be implemented completely, since
they are responsible for system-relevant events, such as PowerOn.

MOST NetServices Layer I 2.x and 3.x

In the case of the MOST NetServices Layer I 2.x and 3.x, the callback functions forunused events do not have to be declared. The MOST NetServices ensure a defined
behavior. It is differentiated between module specific standard callback and generalstandard callback functions:

The module specific standard callback functions are called for a specific eventby only one module.

The general standard callback functions, however, can be called by several
modules. They usually indicate the result of interactions with the network interface.

MOST NetServices Layer II 1.x, 2.x and 3.x

Like the MOST NetServices Layer I, Layer II also defines type A and type B functions. Additionally, version 1.x and 2.x define type C functions. Type C functions
must be explicitly activated by the programmer in a header file (adjust*.h).

9.4.2

Main Loop Architecture

On small processors without a multitasking system software, all applications andservices – except for Interrupt Service Routines – are usually called cyclically froma loop in the main function of the software. The programmer must ensure that for
all applications and services the maximum response time until the next call of theircentral entry function is observed and that the maximum execution time until thenext return to the Main Loop is not exceeded.
For MOST NetServices 1.x, the cyclical call of the services must be within 15 ms.
Otherwise, central functions of the MSV, such as checking the lock status and similar operations, can no longer be assured to meet the MOST Specification. The
maximum return time is typically less than 1 ms, unless the MOST NetServices call

9.4 Integration of the MOST NetServices onto the Target Platform 189

callback functions of the applications on their part. In that case the application programmer is responsible for ensuring a return into the MOST NetServices, and thus
into the Main Loop, within the required time.
For the MOST NetServices 2.x and 3.x, the problems are easier to handle because alltime-critical functions are taken over by the INIC itself and the MOST NetServices
running on the host basically only form the interface with the application software.
The maximum response time also has to be observed in this case, particularly because the INIC supervises the communication with the host by means of a Watchdog Timer which is typically configured to half a second. If the INIC does not receive a response from the host within this time, it assumes an error and disconnects
the host from the network. This results in all applications (FBlocks) provided by thedevice in the network being unregistered.
In addition to the main entry functions of the MOST NetServices in the Main Loop,other functions have to be called which provide the MOST NetServices with information as to the timing. They are usually triggered by a timer-controlled Interrupt
Service Routine (MOSTTimerInt). In version 1.x, call frequencies of 1, 10 and 25
ms can be selected. The MOST NetServices 2.x and 3.x have an advanced timer implementation that supports more flexible call frequencies. which uses the timing information provided by the INIC.

9.4.3

Multitasking Architectures

The items mentioned above can also be applied to multitasking architectures. The
Main Loop is, however, replaced by a Task Loop. Usually, the MOST NetServices
run in a loop which, apart from the entry functions mentioned above, only calls
functions necessary for communication with other tasks or drivers. Functions forserving other services and applications are typically integrated in additional tasks.
For the MOST NetServices task, the priority must be selected such that the minimum call frequency of the MOST NetServices 1.x can be guaranteed. Higher priorities will generally only be reserved for tasks with a real-time functionality (such as
audio/video signal processing, timer) or for network drivers with high timing requirements (such as CAN network driver stack). The actual application should
normally run in tasks with a lower priority.
Due to the fact that the MOST NetServices are written in ANSI-C, they are notthread-safe. This means that the API functions may only be called from one context.
This means that the handler functions of the CMD module must be called and thedata must be accessed in the context of the MOST NetServices tasks and not in thecontext of the respective application. The programmer must solve this problem byusing suitable synchronization mechanisms of the system software, such as semaphores. For this purpose, the MOST NetServices 2.x and 3.x offer macros in the190 9: Network Service
configuration files which can be assigned to platform-specific Mutex mechanisms(Mutual Exclusion).
For larger systems with several applications, one could imagine using, instead of
the central command interpreter, an architecture which passes the messages received from the AMS and the MOST High Protocol through task borders. One
could also imagine executing the evaluation of the messages (also a function of the
CMD module) in the context of the respective application task. Such architectures
are also available by third-party providers.

9.4.4

System Management Module

Modules such as the NetworkMaster, PowerMaster and ConnectionMaster are notpart of the MOST NetServices. They can be licensed as reference implementations
from SMSC in the same manner as the MOST NetServices. In contrast to the MOSTNetServices, however, implementations of the device manufacturers are also commonly used here.

191

10
10.1

MOST Interface Controller
MOST Network Interface Controller and MOST Device

Within a MOST device, the MOST Interface Controller possesses the role of a twoway bridge between the MOST network and the interior of the device. Figure 10.1
shows an example for the structure of a typical single-processor style MOST device. The application hardware provides the basis for the characteristic features ofthe MOST device. In this case, a Digital-to-Analog Converter (DAC) followed byan amplifier stage implies the MOST device to be an amplifier.
MOST Device
External Host Controller
Application
FBlock 1…

Enhanced
Testability

NetBlockControl

Application
Hardware

MOST NetServices Layer II
MOST NetServices Layer I

DAC

AMP

Low Level Driver
Control Data,
Packet Data

PowerManagement
Electrical
Control Line
(ECL)

Stream Data

MOST Network Interface Controller
NIC or INIC

Status Monitoring
Wakeup Logic

Optical or Electrical
ReceiverOptical or ElectricalTransmitter

MOST Network

Fig. 10.1: Structure of a MOST Device

An External Host Controller (EHC) processes all software tasks, including controlling of the application hardware and running MOST related routines.
Towards the MOST network, there is a sending path and a receiving path. In thelatter, a receiver translates the signals coming from the MOST network into a form
that can be processed by the MOST Interface Controller. In the sending path, theoutput of the MOST Interface Controller is converted. This is achieved by an192 10: MOST Interface Controller
external circuitry that generates a signal compliant to the underlying physical layer
specification, depending on the chosen physical layer. Signal transmission thenhappens either in the optical domain (optical physical layer), or in the electrical
domain (electrical physical layer).
In order to allow the MOST device to be woken by activity on the network, the receiver is connected to the wake-up area.
The MOST Interface Controller provides the required standardized interfaces forconnecting to the application as well as the MOST network. This allows to send andreceive streaming, control, packet and isochronous data via the MOST network in
an efficient way. On the MOST side, the MOST Interface Controller receives the bit
stream from the physical layer, refreshes this signal, modifies the data if requiredand emits the signal through the sending path. The refreshing is done to compensate
for signal degradation on the physical layer, in order to re-establish signal integrity
for achieving best transmission results.
An important part of the signal handling on the MOST side is synchronization. The
MOST Interface Controller either creates the system wide clock (when being configured as the sole TimingMaster of the system), or synchronizes to the incoming
bit stream (common for the majority of MOST devices). Thus, all MOST devices ina MOST network are synchronized. This allows for an efficient high quality signaltransmission running at a minimum of overhead.
Device wake-up, power management and status monitoring make sure that the
MOST device complies with the MOST specification in terms of start-up, power
consumption in sleep mode and handling of exceptional situations in power supply.

10.2

MOST Network Interface Controller Families

There are two types of MOST Interface Controllers: the Intelligent Network Interface Controller (INIC) and the Network Interface Controller (NIC). While the NICs
represent the first implementations of a Network Interface Controller, their role indevelopment of new MOST systems and devices meanwhile has been assumed by
the INICs for several reasons. One of the most important motivations for this trend
is the increase of robustness and simplification on system level that is associatedwith the usage of the INICs.

10.2.1 INIC
INICs act as simple MOST devices with regard to the MOST network and its management. They can act autarchically, i.e., independent of the EHC, in order to speed
up system start and stabilize the MOST system at the earliest possible point in time.

10.2 MOST Network Interface Controller Families 193

This is a great advantage, particularly if the application on the EHC has a long boottime, or if an error occurs in the application during normal operation.
For the INIC, the function of the entire network has the highest priority. It enables
the network to start up in a controlled manner and it protects the network from undesired side effects in the case of errors in the application software (reset or “hangup”). The name of the related operational mode – Protected Mode – refers to thisfact. This status is adopted accordingly after a hardware reset of the INIC and during the Power-Up.
The INIC is responsible for the basic performance of the MOST device in which it
is utilized. The EHC and the application running on it boot up independent of the
INIC start-up and log on to the INIC upon completion of their initialization.
There is a common API available for controlling the INIC. Communication between the EHC and the INIC is based upon the Port Message Protocol. The specificfunctions of the INIC are modeled as a function block, in accordance with the general approach to MOST devices. The routing of streaming data can easily be controlled via sockets and connections. The application itself does not need to use the
INIC-API directly, but is based on the MOST API (MOST NetServices). The
MOST NetServices control the INIC via the INIC-API using the Port Message Protocol. According to the MOST philosophy, control of the INIC is organized bymeans of a function block (FBlock) called FBlock INIC.
INICs have a fast serial and synchronous interface for streaming, control and packet
data, which is referred to as MediaLB. This interface can be used, for example, toconnect several audio components on a printed circuit board, providing them, e.g.,with streaming data. The INIC drives the basic clocking of the MediaLB synchronized to the MOST network. This interface is implemented in all INICs.
Additional, standardized interfaces allow connecting application hardware and theINIC, e.g., through I²S.
The properties described in this section make the INIC a first choice component as
far as the implementation of new MOST devices and MOST based multimedia systems are concerned.

10.2.2 NIC
Network Interface Controllers (NICs) were the first generation of communication
ICs for MOST. They have meanwhile been supplemented by the INICs, which enable a more robust system design and a faster product realization. Within the MOST
devices, NICs cover the data link layer functionality. They are controlled via a Register Wall (register structure) by means of read/write access to individual storage
positions.

194 10: MOST Interface Controller
In cooperation with a NIC, the EHC is fully responsible for the basic behavior of
the MOST device in which it is implemented. During implementation, it must be
taken care of that boot times of the application are kept short enough to ensurecompliance with the MOST specifications. If there are errors in the application domain, they can, in the case of NIC-based devices, have an effect on the entire system. This was taken into consideration when developing the INIC. As a matter ofprinciple, the INIC encapsulates such application errors locally.
The routing of streaming data is controlled via the registers of the MOST Routing
Table (MRT). A typical NIC is the OS8104A (MOST25).
Flash- based

ROM- based

OS81110OS81120
Cost Down

MOST150

MOST50

MOST25OS81082OS81050OS81092
Cost Down

OS81060
Cost Down

INIC150

INIC50

INIC25

Fig. 10.2: INIC Family Overview and Roadmap

10.3

The INIC Family

10.3.1 Members
For each of the three MOST speed grades - MOST25, MOST50 and MOST150 two INICs are available (see fig. 10.2).
There are flash memory based versions, and ROM based versions that are cost reduced variants of the flash memory based versions. In the flash memory based versions, both, power-up configuration (Configuration String) and the entire firmwareof the INIC can be re-written. The ROM based versions keep their firmware in
ROM and configuration information in OTP memory. The two-part structure of the
OTP memory area of OS81092 allows writing the Configuration String twice.

10.4 Interfaces to the INIC 195

MOST150 constitutes an exception to the description above, since only the flash
based version OS81110 is currently available. The cost reduced version OS81120 isat the planning stage.

10.3.2 Overview of Features
Table 10.1 outlines the general features available in the members of the INIC family. Note that not all interfaces listed in Table 10.1 are available at the same time.
Availability depends on configuration, since some of the interfaces share pins tokeep pin count low.

FeatureData types andInterfaces

Supported Control, Synchronous,
MOST
legacy async. packets
Data Types Isochronous, Ethernet
I²C, I²S, MediaLB
3-pin
Interfaces MediaLB 5-pin (leg(See text)
acy)
MediaLB 6-pin, TSI,
SPI
Power
SupplyPackage

INIC25 INIC25 INIC50 INIC50 INIC150
OS81050 OS81060 OS81082 OS81092 OS81110
X

X

X

X

X
X

X

X

X

X

X

X

X

X

X

X
3.3V /
2.5V
ETQFP
44 QFP
44

3.3V /
1.8V

3.3V /
2.5V

3.3V /
1.8V

3.3V /
1.8V

QFN 40

ETQFP
64

QFN 48

QFN 48

Table 10.1: Features of the INIC Family

10.4

Interfaces to the INIC

10.4.1 Available Interfaces
Regardless of the MOST network speed grade, all members of the INIC family
have a similar general structure. The INIC processor - shown in the center of Figure10.3 - transmits the data from and to the MOST network and takes care of the routing of the data from and to the peripheral interfaces.

196 10: MOST Interface Controller

StreamControlPower
Monitor &Control

MediaLB

TSI
OS81110 only

INIC APIINIC Processor
FBlock INIC

INIC
MemorySPI
OS81110 only

JTAG
Port /
Debug Port

FBlock NBMin

NetServices Minikernel

Clock
Manager

MOST Network Port

Fig. 10.3: INIC Block Diagram

The clock manager is responsible for providing the clock to the entire chip, the application hardware and – once the INIC is configured in TimingMaster mode – also
for the entire network. It ensures overall synchronization.
The Power Monitor & Control module establishes the connection to an externalPower Management circuit. The INIC can thus react to changes in the power supply
in accordance with the MOST Specification.
By means of the JTAG / Debug Port, the INIC can be included in boundary scan
testing. The same interface supports debug level access to the INIC. Connected toan INIC Explorer, internal data like power-up configuration and property values,
stream data routing information and interface configurations can be retrieved. The
possibility to write the Configuration String on flash based and ROM based INICs
is very useful too. It makes sense to implement at least the footprint for the
JTAG/Debug Port related connector (not populating it in mass production) on theprinted circuit board (PCB).
The INIC Memory block shown in Figure 10.3 actually stands for different kinds ofmemory. It keeps continuously changing data, as well as start-up configuration data
(Configuration String) and special data that needs to be kept between the system's
life cycles during sleep phases.
External devices like analog-to-digital converters (ADCs), or digital-to-analogconverters (DACs), or DSPs, or similar, interface to the Streaming Port. The
Streaming Port can source or sink streaming data in various industry-standard
formats.

10.4 Interfaces to the INIC 197

All INICs have a MediaLB interface for streaming, control, packet and isochronous
data. This interface can be used to connect different audio or video components on a
printed circuit board, using the INIC as a bridge, to the MOST domain. Since theclocking on MediaLB is synchronized to MOST, the synchronous network approach of MOST is maintained even at PCB level. The kinds of data available on
MediaLB and the available MediaLB interface types (MediaLB 3-pin, MediaLB 5pin, MediaLB 6-pin) depend on the used INIC and its configuration.
Industry devices like satellite tuner devices, receivers, displays, or video decoders,typically handle Transport Stream Interface (TSI) data streams. OS81110, the INIC
for MOST150, has a special interface to establish a connection with such devices
for transporting TSI streams over MOST, the TSI port.
Many microcontrollers and peripheral devices make use of the serial peripheral interface (SPI). The SPI port of the OS81110 is implemented as the typical four pin
interface. It uses an additional interrupt pin for flow control and can transport either
asynchronous packet data, or QoS IP packets (isochronous).
Audio, Video
Packet, Control
Ethernet/
Packet

Audio

Control/
Packet

over

over

over

I2S

I2C

SPI

over

INIC25 and INIC50

Video
over

Generic

Serial TSI Clock IO

6-pin

3-pin

MediaLB

INIC150

Fig. 10.4: INIC Connectivity Overview Diagram

The I²C based Control Port allows direct communication between the EHC and theINIC. It transports data based on a message based protocol. Through the Control
Port, the EHC can access FBlock INIC and can send and receive legacy packet data
and MOST control messages (MCM).
Last but not least, all INICs establish the connection to the MOST network at the
MOST speed grade they are designed for. The MOST Network Port is specificallydesigned to accomplish this task and therefore represents the interface to the particular MOST network. It recovers the MOST network clock, decodes incoming
data, encodes data in the outgoing direction and refreshes the signals towards its
output to achieve the best possible transmission quality.

198 10: MOST Interface Controller
10.4.2 Interfaces from Software Perspective
Overall Structure

All internal functions of the INIC are accessible through the so-called INIC API,
using the Port Message Protocol. The specific internal functions of the INIC aremodeled as a function block (FBlock INIC), in accordance with the general approach to MOST devices. Function block NetBlockMin (NBMIN) allows the INIC
to act autarchic towards the Network on absence of a running application software.
The MOST NetServices MiniKernel contains crucial MOST NetServices functionality that relieves the EHC of real-time style supervision tasks. It also contributes tothe capability of the INIC to act independent of the EHC. The application itself does
not use the INIC-API directly, but is based on the MOST API (MOST NetServices).
The MOST NetServices control the INIC via the INIC-API and Port Message Protocol.

I2C

MediaLB

INIC API (Port Message Protocol)
INIC Message
Interface

MCM
Rx & Tx FIFOs

MDP
Rx & Tx FIFOs

ICM
Rx & Tx FIFOs

MOST
Supervisor
API

SocketConnection
ManagerAPI

INIC
Communication
FunctionsAPI

Coordination
Functions
API

FBlock NetBlockNBMIN

General INIC
Functions
API

FBlock INIC

MOST Processor
Control Service(MCS)

SocketConnection
Manager(SCM)

MOSTSupervisor(MSV)

Asynchronous
Data Service
(ADS)

INIC
Segmentation
Service(ISS)

Control Message
Service(CMS)

MOST NetServices MiniKernel

MOST Network

Fig. 10.5: INIC Software Stack Overview

INIC Message Interface

For communication towards the EHC, the internal structure of the INIC is organized
in a threefold way. The INIC Message Interface consists of three sets of buffers that
correspond to three different kinds of messages.

10.4 Interfaces to the INIC 199

MOST Control Messages (MCM) are identical to MOST Control Messages thattravel over the MOST network for the purpose of control level communication.
MOST Data Packets (MDP) and MOST Ethernet Packets (MEP) both refer to packetized data. While MDP belongs to the legacy packet data that is available on
MOST networks since the implementation of MOST25, MEP contain packet data
for Ethernet style data transfer.
INIC Control Messages (ICM) have the same structure as MCM, but are directed
only towards FBlock INIC. The EHC uses ICM to control and configure the INIC
during runtime, while the INIC replies accordingly, e.g., with status reports.
Function block NBMIN and FBlock INICAs explained in the introduction to this chapter, INICs can act as simple MOST devices with regard to the MOST network and its management. Since every MOST
device must stringently contain the functionality of the function block (FBlock)
NetBlock, the minimum version of a NetBlock, the NetBlockMin (NBMIN) is integrated into the INIC, too. Together with the NetBlock EHC (NBEHC) of the application it forms the normal NetBlock (see fig. 10.6).
NBMIN has a proxy like role, when the EHC, the MOST NetServices and the application are present. If the INIC needs to act independent of the EHC, it takes full
responsibility and makes the MOST device a device without function blocks.
The FBlock INIC is the lean interface to control INIC hardware functionalities andthe MOST NetServices MiniKernel. It allows access, e.g., to the Notification function of the INIC, to information such as version info and to the control mechanisms
for streaming data.
MOST NetServices MiniKernel

The routines of the MOST NetServices MiniKernel handle, e.g., MOST control
Messages and data packets. They configure the INIC on start-up and control, e.g.,
the routing of stream data. The MOST Supervisor has an important role in the
MOST NetServices MiniKernel. It handles dynamic network events, network supervision, power management and errors. In general it controls the behavior of the
INIC in the MOST network context and therefore takes care of, e.g., start-up andshutdown, configuration of the INIC as TimingMaster or TimingSlave.

200 10: MOST Interface Controller

EHC
Application
FBlocks
NetBlock
NBEHC

MOST
NetServices

NetBlock
NBMIN

FBlock INIC

Interface Controller Core

INIC

Fig. 10.6: NetBlock NBMIN and NetBlock NBEHC

10.4.3 Ports, Sockets and Connections
From the perspective of the INIC, the periphery and the MOST network are connected via ports. Their start-up configuration is partially achieved via hardware
pins, but mainly by access to the properties and methods of the FBlock INIC via the
INIC-API. While the Network Port – the gate to the MOST world – can transport
all MOST data types available, other ports are specialized to one or more datatypes. Depending on the configuration, the hardware of the ports is able to moveseveral data streams in different directions.

StreamControl MediaLB

SPI

TSI

OS81110 only

OS81110 only

INIC
MOST Network Port

Fig. 10.7: Ports of the INIC

Ports need to be opened. Some ports are opened automatically, based on the configuration of the INIC. Other ports are opened by accessing the OpenPort functionof the INIC API.

10.4 Interfaces to the INIC 201
INIC
Streaming Port

SX0

Control Port
PacketIn
PacketOut

StreamOut

Control
In
Control
Out

SH=00

MOST Network Port
PacketOut
PacketIn

Stream...

Control
Out
ControlIn

MOST Network

PacketControl

MOST Network

Fig. 10.8: Sockets at the MOST Network Port (MOST25). SH – Socket-Handle

Which data type is to be accessed directly and which direction is desired (IN or
OUT) is defined by means of sockets.
Note: Data directions are always described from the perspective of the INIC. If data
move into the component, this corresponds to the direction IN, if they flow out of
the component, this corresponds to the direction OUT.
INIC
SX0

Streaming Port
SX1

SR0
StreamIn

Control Port

SR1
Stream
In

StreamOut

Stream
Out

SH=00

SH=01

SH=02

SH=03

CH=00

CH=01

CH=02

CH=03

SH=04

SH=05

SH=06

SH=07

StreamOut
Stream
In

StreamOut

Stream
In

PacketIn
PacketOut

MOST Network Port
PacketOut
PacketIn

0x00, 0x01, 0x04, 0x05, 0x08, 0x09,
0x02, 0x03 0x06, 0x07 0x0A, 0x0B

Control
In
Control
Out

Control
Out
ControlIn0x28, 0x29,
0x2A, 0x2B...

StreamPacketControl

MOST Network

Fig. 10.9: Ports, Sockets and Connections

If a socket is generated, the INIC returns a confirmation message and an
identification (Socket Handle [SH]). Establishing a connection then enables the data
flow. The function for establishing the connection requires the Socket Handle of the202 10: MOST Interface Controller
IN-Socket and the one of the OUT-Socket only. Establishing the connection results
in a Connection Handle, which is required for connection management (also forremoving the connection).
Note: It is only possible to connect sockets of type IN and OUT that have the same
type of data and the same parameter settings.

10.4.4 Port Message Protocol
Line 1

Port Message (PM)Line 2PML

Line 3PML

PMHL

PM Header (PMH)

PM Body (PMB)

PM Header Body (PMHB)

PM Body (PMB)

Line 4PML

PMHL FPH

HandleFIFO Command

HandleFIFO Status

Line 5PML

PMHL FPH

Line 6

PML

PMHL

FPH

FIFO Data Header

FIFO Data Body

MCM FIFO Data Read/Write:FktID

MDP FIFO Data Read/Write:

OPType TelID

TelLenLengthMEP FIFO Data Read/Write:

DestAddr

ICM FIFO Data Read/Write:

FktID

Data[0, 1:n]Data[0:(m-1)]

SrcAddrVLAN

OPType TelID

Type

TelLenData[0:(k-1)]

FCS

Data[0, 1:n]

Optional

Fig. 10.10: Port Message Protocol Structure

Message exchange between INIC and the EHC is based upon the Port Message Protocol. Figure 10.10 depicts the elements of the Port Message Protocol, some ofwhich are optional. A Port Message (PM) (see “Line 1” in fig. 10.10) consists ofseveral parts.
The Port Message Length (PML) (see “Line 2” in fig. 10.10) is a 16-bit value,
which counts the bytes of the PM Header (PMH) and the PM Body.
The PMH (see “Line 3” in fig. 10.10) consists of the eight-bit PM Header Length(PMHL) value and the PM Header Body (PMHB). PMHL counts the bytes of
PMHB. PMHB either contains FIFO commands (see “Line 4” in fig. 10.10), FIFO
status information (see “Line 5” in fig. 10.10), or information on the subsequent
data (see “Line 6” and below in fig. 10.10).
The FIFO Protocol Header has an important function in differentiating between the
different message types that are available:


FIFO Command messages
Used to resynchronize INIC’s interface or retry failed messages

10.5 Protection, Encapsulation and the EHC 203

FIFO Status messages
Used for handshaking and to indicate that INIC’s initialization is complete

MOST Control Messages (MCM)MOST Data Packets (MDP)

MOST Ethernet Packets (MEP) OS81110 only

INIC Control Messages (ICM)

If the PM Body is available in a particular PM, it contains the message data itself,
according to the specific structures.

10.5

Protection, Encapsulation and the EHC

10.5.1 Interaction between INIC and the EHC
In order to protect the network from undesired side effects, the cooperation between
INIC and EHC is controlled via a state machine, the External Host Controller Interface State Machine (EHCI-State).
The EHCI State Machine can reach three states (see fig. 10.11):


EHCI-Protected

EHCI-Semi-Protected

EHCI-Attached

EHCI-Protected

The INIC takes on the EHCI-Protected basic state after a reset. It effectively prevents a starting or incorrectly running application from accidentally having accessto the MOST network. The application should finally reach the normal operating
mode, state EHCI-Attached, via the EHCI-Semi-Protected state.
In state EHCI-Protected it is not possible for the EHC to send messages to othernodes in the MOST network. The EHC cannot receive messages from the MOST
bus either. The safety concept of the INIC provides for the application being
watched by the INIC. For this purpose, the INIC has a so-called Watchdog mechanism. The INIC-API allows the configuration of the Watchdog and the change ofstate of the EHCI State Machine while in the EHCI-Protected state.
A handshake procedure makes sure that both, INIC and EHC, are informed about
the readiness of the respective partner. If they are ready, the application running on
the EHC configures the Watchdog mechanism (if required) and starts changing to
the next state.

204 10: MOST Interface Controller
Reset

INIC.EHCIState.Set (Protected)
or any Watchdog timeout

EHCI
Protected

INIC.EHCIState.Set (Protected)
or any Watchdog timeout

INIC.EHCIState.Set(SemiProtected)

EHCI
SemiProtec
ted

EHCI
Attached

Any Rx Control Message or
INIC.Watchdog.Start ()in time and all Tx Status Messages

Any Rx Control Message or
INIC.Watchdog.Start ()in time and all Tx Status Messages
INIC.EHCIState.Set (Attached)

Fig. 10.11: The states of the EHCI State Machine

EHCI-Semi-Protected

The state EHCI-Semi-Protected also prevents communication with the MOST network. It allows, however, full access to the FBlock INIC. The underlying concept
takes into consideration that the full initialization of the hardware of a MOST device also requires the start-up of such applicative parts of the connection, which
possibly require, e.g., a continuous clocking.
In this state, the EHC can therefore configure and open ports, such as the Streaming
Port. When opening the ports, the respective hardware interfaces start operating,thus also providing the clocks for external synchronizing purposes.
If all hardware initializations are finished, the change to state EHCI-Attached canbe performed.
EHCI-AttachedIn the state EHCI-Attached, the EHC has full, bi-directional access to all data typesof the MOST network. The application is also fully available for the network andthe applicative function blocks (FBlocks) must be registered at the NetworkMaster.
Consequences of EHCI State and NetBlock

In the state EHCI-Protected and the state EHCI-Semi-Protected NBMIN takes on
the role of the main contact with regard to administrative queries from the network.
Due to the fact that certain information is only available when the application isready for operation, certain queries are acknowledged either with an empty list orwith an error message.

10.6 Configuration through Configuration String 205

The NBMIN also answers corresponding administrative queries in the state EHCIAttached. Application-related queries to the EHC and its NetBlock (NBEHC), however, are then passed on to the application.

10.5.2 The Watchdog Functionality
In general, watchdog circuits are used to supervise applications with regard to malfunctions. For that purpose, a signal is implemented in the application, which, innormal operation, appears cyclically. This signal is applied to the watchdog circuit.
If the signal fails to appear, this can be interpreted as an indication of a malfunction.
For eliminating a malfunction, discrete watchdog circuits often trigger a hardware
reset and consequently a re-initialization of the complete application.
In the case of the watchdog mechanism implemented in the INIC, messages which
are exchanged between INIC and application, take on the role of the signal. Supervision is implemented individually for the sending and receiving direction. The timeinterval, which is set by the application during initialization and used during runtime, is valid for both directions.
When data is received from the EHC, the INIC continuously supervises whether theapplication regularly sends valid messages within the set time interval. Usually, theapplication communicating to the MOST network during normal operation ensures
the necessary signaling. Should communication with the network not be necessary,
the application will continue to trigger the watchdog.
In the sending direction, supervision only takes place if the INIC has sent a message
to the application. In this case, the INIC supervises that the acknowledgement of reception for the sent message arrives within the defined time interval.
If the INIC detects a violation of the time interval, it protects the network from effects resulting from the obvious malfunction of the application by the EHCI State
Machine carrying out a change to the EHCI-Protected state. In addition, the INIC
has a dedicated reset output for the application. When this option is activated, by arespective configuration by the application, the INIC then triggers a hardware reset,
e.g., of the EHC.

10.6

Configuration through Configuration String

Since the completion of the EHC start-up usually takes some time, there is a Configuration String inside the INIC, which contains a sequence of values that allow
controlling the initialization of hardware and firmware of the INIC at the earliest
possible moment during MOST device start-up.

206 10: MOST Interface Controller

Fig. 10.12: Exemplary INIC Configuration String of OS81110

The Configuration String can be modified either through the ECH, or through INIC
Explorer. On ROM based circuits, the Configuration String can be written twice.
Flash based INICs allow modifying the Configuration String as required.

10.7

Control Port

SDA

INT

StreamSCL

The Control Port is based on the I²C-Bus, i.e., on serial data transmission by meansof a clock line, a data line and an interrupt line. With regard to the I²C, the INIC behaves as I²C-Slave supporting Clock Stretching.

Control MediaLB

SPI

TSI

OS81110 only

OS81110 only

INIC
MOST Network Port

Fig. 10.13: INIC Control Port

10.8 Streaming Port 207

The INIC signals the availability of data by means of an Interrupt Pin (INT). The
Control Port transports control and/or packet data between INIC and EHC. In addition, it can be used to write firmware and configuration data to the INIC. The I²C
address used for the Control Port is specified in the Configuration String.

10.8

Streaming Port

The Streaming port connects INIC to multimedia sources and/or sinks using serial
point-to-point connections. It is synchronized to the MOST network and provides
up to 4 serial data pins, which are configurable with respect to direction, data rateand data format. The Streaming port is configured through INIC API.
It supports several different data formats and provides 2 clock pins to synchronize
external hardware to the MOST clock. Maximum clock speed is 512 Fs (forOS81110 only).

clock

SX0
SX1
SR0
SR1

Data
(example)

FSY
SCKStreamControl MediaLB

SPI

TSI

OS81110 only

OS81110 only

INIC
MOST Network Port

Fig. 10.14: INIC Streaming PortAll data signals of the Streaming Port share one clock pin (SCK) and one synchronization pin (FSY; for differentiating between Left/Right). If FSY and SCK areconfigured as output, they drive the serial data transmission on the Streaming Port.
In this case, the externally connected peripheral components have to synchronize to
FSY and SCK. It is possible to configure FSY and SCK as inputs. When doing so,
the synchronization of these signals must take place via the RMCK (Recovered
Master Clock) output of the INIC.
Those connections at the INIC that transport Streaming Data serially towards theperiphery (out of the INIC) are called SX0 and SX1. From the perspective of theapplication, they are the sources of the Streaming Data. Accordingly, there are thedata sinks SR0 and SR1, which transport data from the periphery into the INIC.

208 10: MOST Interface Controller
10.9

SPI Port

The SPI port of the OS81110 is implemented as shown in figure 10.15. It can operate at a clock rate of up to 25 MHz (SCLKn = 512*Fs @ 48kHz) as SPI slave.

CS
SDIN
SDOUT
SCLK

The INIC receives information about the direction of a data transfer from the SPI
bus master through SDIN.

StreamControl MediaLB

SPI

TSI

OS81110 only

OS81110 only

INIC
MOST Network Port

Fig. 10.15: INIC SPI Port

10.10 Transport Stream Interface (TSI)

StreamControl MediaLB

TVAL
TSYN

TDAT
TCLK

The OS81110 has a serial 4-pin TSI interface capable of operating at bit rates up to
50 Mbps (1024*Fs). It supports TSI Master mode (transmission) or TSI Slave mode
(reception).

SPI

TSI

OS81110 only

OS81110 only

INIC
MOST Network Port

Fig. 10.16: INIC TSI Port

The TSI port packet structure uses a packet size of 188 Bytes. OS81110 has up to
two 2 TSI ports that can run simultaneously.

10.11 MediaLB Port
The Media Local Bus (MediaLB) was developed to be able to transmit all types ofmultimedia data and additionally transmit data for controlling applications (see the10.11 MediaLB Port 209

most current MediaLB specification) [MediaLB]. These properties make it different
from the generally used and highly specialized serial interfaces. It is a transmission
medium which is synchronous to the MOST bus. It is used on printed circuit boards
to connect different integrated components in a way that saves board space andkeeps pin-count low.

MediaLB Physical Interface
MediaLB
Signal NamesMediaLB Clock(MLBC)MediaLB Signal(MLBS)MediaLB Data
(MLBD)

3-pin(single-ended)

5-pin(single-ended)

6-pin(differential)

MLBCLKMLBCLKMLBSIG

MLBSI
MLBSO
MLBDI
MLBDO

MLBCP
MLBCN
MLBSP
MLBSN
MLBDP
MLBDN

MLBDAT

Table 10.2: Nomenclature of MediaLB Signals

MediaLB can be implemented with 3 pins, 5 pins, or 6 pins. The 5-pin MediaLB
was specified to enable such components to be equipped with MediaLB, whichhave unidirectional pin circuits only. This results, however, in more space being required, additional logic circuits being used and the maximum speed being lower. In
practice, the 3-pin model is thus mostly used, followed by the 6-pin MediaLB. MediaLB uses the following signals. For detailed naming information see Table 10.2:


MLBCLK (MediaLB Clock, uni-directional)

MLBSIG (MediaLB Signal, bi-directional)

MLBDAT (MediaLB Data, bi-directional)

MLBC provides the timing for the entire MediaLB system. It is created by the MediaLB Controller and supports multiple clock rates. MLBC is synchronous to the
MOST network and an input for all MediaLB devices. This principle is valid for all
MediaLB implementations. Figure 10.17 shows the wiring for a 3-pin MediaLB
implementation. For MediaLB 6-pin, there are modes which internally multiply thefrequency of the MLBC signal by means of a PLL, so that the data transfer actuallyis based on an internally “recovered” clock that runs at higher speed. So there is adifference between the external and the actually used clock.

210 10: MOST Interface Controller

ActualMLBCLK

256*Fs
512*Fs
1,024*Fs
2,048*Fs
3,072*Fs
4096*Fs
6144*Fs
8192*FsMediaLB
3-pin

5-pin

X
X
X

X
X

Quadlets
per Frame

PhysicalChannels

6-pin

X
X
X
X
X

PhysicalChannelsavailable
for theapplication

8
16
32
58
87
117
161
215

PC0 - PC7
PC0 - PC15
PC0 - PC31
PC0 - PC57
PC0 - PC86
PC0 - PC116
PC0 - PC160
PC0 - PC214

7
15
31
57
86
116
160
214

Table 10.3: Number of channels depending on the clock rate on MLBC

MOST Network

MediaLB
Controller

RXMediaLB
Device 1

MLBDAT

MLBDATMLBSIGMLBSIGMLBCLKMLBCLK

TX

MediaLB
Device 3MediaLB
Device 2

MLBDAT

MLBDATMLBSIGMLBSIGMLBCLKMLBCLK

Fig. 10.17: Connection diagram of a 3-pin MediaLB implementation

In a MediaLB Bus, there is a MediaLB Controller, which is responsible for generating the clock. The MediaLB devices operate their MediaLB interface according tothis predetermined clock.
Depending on the clock rate, there are different transport capacities available on theMediaLB (see Table 10.3). Four subsequent bytes (4 bytes = quadlet) are combined
to form a physical channel. The first Physical Channel (PC0) of a MediaLB Frameis reserved for the System Channel, as it is called.

10.11 MediaLB Port 211

One or more Physical Channels can be combined to form a Logical Channel having
a specified, unambiguous ChannelAddress. Logical channels operate unidirectional
and transport only one type of data, which is selectable.
3.3 V

MediaLB Device 1

MLBCN
MLBCP
Network Port

MOST Network

MediaLB Controller

MLBSN
MLBSP

MLBDN
MLBDP

MLBCN
MLBCP

MLBC

MLBSN
MLBSP

MLBS

MLBDN
MLBDP

MLBD

MediaLB Device 2

MLBCN
MLBCP
MLBSN
MLBSP

MLBDN
MLBDP
MediaLB Device 3

MLBC

MLBS

MLBD

MLBCN
MLBCP
MLBSN
MLBSP

MLBDN
MLBDP

Fig. 10.18: Connection diagram of a 6-pin MediaLB implementation

MediaLB uses a time-multiplexed bi-directional signal line for ChannelAddresses,
Commands and RxStatus signaling. This line is called MLBS. Opposite to the
MLBC, it can be read and driven by all MediaLB devices. ChannelAddresses indicate which device can transmit data when and which devices can receive data on aparticular logical channel.
The MLBD signal is the time-multiplexed bi-directional data line, which also canbe driven or read by all devices. At a given time, only one device is allowed to drive
this line. It is possible that more than one device is listening to MLBD.
Due to the fact that the MediaLB runs synchronously to the MOST network, theMediaLB is also organized in frames.

212 10: MOST Interface Controller
The control of the bus access is achieved on the level of the logical channels via thechannel addresses. The MediaLB controller arbitrates data transfer amongst all MediaLB devices. The actual access is then carried out at a distance of one quadlet. It
is used, e.g., by a MediaLB Device for sending out streaming data.
The separation into frames is done by means of a specific identification, the
FRAMESYNC pattern. This pattern is also generated by the MediaLB Controller
and signals that after one quadlet, the next frame with its system channel will start(see fig. 10.20).
Controller grants theTransmitting Device (Tx Device)access to the logical channel
associated with the ChannelAddress.

PC n-2MLBSIG

Receiving Device (Rx Device)accepts or rejects the datausing the RxStatus field.

Transmitting device (Tx Device)transmits its Command and theassociated data.

PC n-1

PCn

Controller
ChannelAddress

MLBDAT

Tx Device
CommandRx Device
RxStatus

Tx Device
Data 0Tx Device
Data 1

Controller
ChannelAddress
Tx Device
Data 2Tx Device
Data 3

4-bytes Delay(1 quadlet = 1 physical Channel)(1 quadlet = 1 physical Channel)

Fig. 10.19: Block Data transmission on the MediaLB

PC0MLBSIGMLBDAT

PC1

PC6

PC7

Byte

Byte

Byte

Byte

Byte

Byte

Byte

Byte

Byte

Byte

Byte

Byte

Byte

Byte

Byte

Byte

0

1

2

3

4

5

6

7

24

25

26

27

28

29

30

31

Sys
Cmd

etc.

Controller
FRAMESYNC

Controller
Data

SystemChannel

4-byte Delay(1 quadlet = 1 physical Channel)

Fig. 10.20: MediaLB frame and the FRAMESYNC pattern (at 256*Fs)

The extended clocking options for MediaLB 6-pin and the design of the signal lines
significantly increases data throughput on MediaLB. Further information can befound in the MediaLB Specification.

10.12 Power Management
The INIC supports external power management circuits by means of two separate
input pins. Depending on the state of these pins, the INIC reacts according to the
MOST Specification.

10.13 Intelligent Muting 213

PS1

PS0

Status

0
0
1
1

0
1
0
1

UNormalSwitch-To-Power (STP)
UCritical
ULow

Table 10.4: Input Pins for external Power Management

10.13 Intelligent Muting
Streaming connections in a MOST network are established between the devices asneeded and usually stay alive as required. Nevertheless, there are imponderabilities
that might lead to disturbances in the network and to unwanted audible or visible effects. The built-in intelligent muting of the INIC allows to automatically mute sinksocket connections to prevent the application from receiving corrupted streaming
data. Intelligent muting is triggered by either an unlock, or on occurrence of a Network Change Event (NCE, related to an MPR change - for instance when one node
has left the ring).
Automatic muting is available for synchronous data, and DiscreteFrame Isochronous Streaming data (IsocDiscFrameData) on both, the Streaming Port and the MediaLB Port.

10.14 Network Interface Controller (NIC)
10.14.1 Available Interfaces
In contrast to INICs, Network Interface Controllers (NICs) are controlled by direct
read/write access to individual memory locations. The roles of the existing interfaces therefore have a different definition than in the case of INICs. The application
running on the EHC is responsible for the behavior of the entire device, e.g., forstart-up and error management.
This resulted in a few obstacles for the MOST systems of the first generation, whichwere taken into account when developing the INIC. One of these obstacles was thedelayed start-up of the application of some devices. Due to the bypass being closed
for too long, there was a risk of delayed system starts or of instabilities because of
missing data recovery. Errors in applications could trigger errors in the recording ofstorage positions in the NIC. This in turn had effects on the entire MOST network.

214 10: MOST Interface Controller
These weaknesses were addressed by encapsulating these mechanisms within the
INIC. At the same time, the Media Local Bus (MediaLB) replaced the available 8bit interface of the NIC, which resulted in less space requirements and less implementation expenses. This is why new developments are realized with the INIC.

Fig. 10.21: Block diagram of an
OS8104A

This section takes the NIC component OS8104A as an example. It has meanwhile
replaced the NIC of the first generation (OS8104) when updating existing designs.
The basic configuration of the OS8104A is done during the hardware initialization,
via the Configuration Interface (CI).
The Control Port (CP) allows write/read access to the internal memory of the NIC.
It thus enables fine tuning configuration of the component, but also communication
via Control Messages and packet data transfer up to 48 bytes packet length. Also
routing, i.e., processing of the streaming data, is controlled via CP. It can be operated in serial or in parallel.
It is the main task of the Source Port (SP) to transport streaming data. As the hardware of the SP is generally able to handle very high data rates, there are further
modes for the SP in parallel operation:

Parallel-Asynchronous mode

Parallel-Synchronous modePhysical (Parallel-Combined) mode

10.14 Network Interface Controller (NIC) 215

10.14.2 Serial Operation
CP

In serial operation, the CP can transmit data either in the I²C format (as I²C-Slavewith Clock Stretching) or in the SPI format.
SP

Similar to the INIC, the data signals of the Source Port share a Clock Pin (SCK) anda Synchronization Pin (FSY, for distinguishing left/right). If FSY and SCK are configured as outputs, they drive the serial data transmission on the Streaming Port. In
this case, the externally connected peripheral components must synchronize to FSY
and SCK. If this is not possible, FSY and SCK can be configured as inputs.

10.14.3 Parallel Operation of CP and SP
Note: If FSY and SCK are configured as inputs, the synchronization of the application must take place via the RMCK (Recovered Master Clock) output of the NIC.
CP

In parallel operation, data is written to or read from the memory of the NIC in abyte-wise manner. The parallel operation requires additional control signals, which
are described below.
SP

The parallel operation significantly increases the data throughput of the SP. Performance is so high that a single component per MOST Frame can simultaneously
read the complete 60 bytes streaming data from the MOST network and write back
60 new bytes. In the Physical Mode, 64 bytes per frame can flow from the application to the MOST network and back. In this case, additional control information for
the interface operation is included.

10.14.4 Possible Configurations (Serial/Parallel)
It is possible to operate the NIC in a completely serial or completely parallel manner. There is also a combination of serial and parallel operation, in which the Control Port is operated in the serial mode and the Source Port already in the parallelmode.

216 10: MOST Interface Controller
S/PDIF,
2
I S,...
2

2

I C / SPII C / SPI

CP

CP

CP

SP

SP

SP

8

8

S/PDIF,
2
I S,...

serial SP / serialCPparallel SP / serialCPparallel SP / parallelCP

Fig. 10.22: Possible basic configurations for CP and SP

Note: If parallel operation is selected, the serial Source Port pins (SX0 to SX3, andSR0 to SR3) are no longer available. They are converted to an 8-bit wide data bus.

10.14.5 The Basic Configuration of a NIC
The basic configurations for parallel or serial operation are done during the hardware initialization. The Configuration Interface, as it is called (a group of connection pins), provides this in cooperation with the Reset Pin of the NIC. It consists ofthe following pins:


PAR_CP (Control Port parallel)

PAR_SRC (Source Port parallel)



ASYNC (parallel asynchronous mode of the SP)

LEG (OS8104 compatibility mode)SCL (Clock of the serial CP interfaces)

These pins are read with the rising edge of the Reset Pin. The NIC then carries out
the relevant internal configuration. It signals the end of the configuration and thus
readiness for operation by means of triggering off the first interrupt (Power-On Interrupt).
Note: Before the first access to the CP, the application must, by all means, wait for
the Power-On Interrupt.

After that, none of the pins – except the SCL – must change their mode. SCL is a
Clock Pin which is used in the serial CP Interface. Depending on the selected bus,
this pin is either at logic “1” (I²C) or at logic “0” (SPI) in idle mode. It is assumed
that in the case of the Reset there are no data transmissions into the CP, i.e., there is
an idle phase, in order to enable proper detection.

10.14 Network Interface Controller (NIC) 217

10.14.6 Interfaces for Control Data in NICs
Control data is always fed into the component via the CP and read from there, independent of the CP being operated in parallel or serial. The Control Messaging isbased on internal buffers of the NIC, i.e., a group of correlated registers.

10.14.7 Interfaces for Streaming Data in NICs
The SP provides for a multitude of streaming formats and data rates in both, the serial and the parallel mode. Control of the flow of Streaming Data is ensured via the
MOST Routing Table (MRT). This table controls the Routing Engine, which carries
out the actual data transport.
In the serial mode, eight serial Interface Pins are available at the maximum. Depending on format and speed, they can all operate simultaneously. There are fourpins in each direction (in/out) to which A/D converters, codecs or DSPs can be connected.
The highest throughput of Streaming Data is obtained via the Parallel Synchronous
Mode of the SP. The Physical Mode is based on the same Interface Mode. It has thesame throughput with regard to the Streaming Data.

10.14.8 Interfaces for Packet Data in NICs
Packet data can be sent and received via the internal memory of the NIC. There,
data is accessible either via the CP, or the SP in the Parallel Asynchronous Mode.
The maximum payload is 48 bytes in this case.
If longer packet lengths and thus higher data throughputs are required, the PhysicalMode (Parallel Combined Mode) can be used. This interface requires an appropriately dimensioned connection to the application.

218

219

11

Tools

11.1

Overview

The development process of MOST systems uses the well-known V-Model. The
left side of the V-Model, as illustrated in figure 11.1, is composed of three phases.
In the market, there are same simulation and analysis tools that represent thesephases.
Phase 1

Design andAnalysis Tools

simulated
Nodesimulated
Nodesimulated
Nodesimulated
Bus

Virtual system

Phase 2
physicalBus

Design andAnalysis Tools

real
Node

Real partial systemsimulated
Nodesimulated
Node

Virtual partial system

Phase 3
physicalBussimulatedBus

Design andAnalysis Tools

real
Node

real
Node

real
Node

Fig. 11.1: The development process from network simulation to thereal total system (according to [vector])

Real system

In phase 1, the simulation of the complete system with respect to the requirements
takes place. Here, the functional and communicated behaviors of the MOST nodes
will be verified. In this phase, the function blocks are defined by a MOST editor
and the dynamical behavior is described by an MSC editor (refer to section 11.2).
During phase 2, the MOST ECUs are developed and integrated step by step into the
network. There are real and virtual ECUs in this phase, which is called Remaining
Bus Simulation as well. Rapid prototyping tools drive push on this process (refer tosection 11.4). Software libraries for the Network Service (refer to chapter 9), which
are promoted by several software houses, support the software development. INIC
Remote Viewer and MediaLB Analyzer provide the hardware development (refer tosection 11.5).

220 11: Tools
In phase 3, all real ECUs are available. The complete system can be tested and verified now.

Network test
Node test

Node test

Compliancetest

Protocoltest

Function
test

Compliancetest

Protocoltest

Function
test

Node 1

Fig. 11.2: Overview over thetest levels of a MOST system

Tests of the single MOST ECUs and the complete network take place in phases 2
and 3. Figure 11.2 illustrates the necessary test levels. At first, function and compliance tests are executed of a single ECU. The function tests warrant the accurate implementation of the user application, and the compliance and protocol tests checkthe correct communication behavior in regard to the MOST Specification. Following, the complete MOST network is tested in the lab, then on the test board and finally in a car. Chapter 12 introduces the compliance tests and chapter 13 the MOST
tests.

11.2

Specification Tools

11.2.1 MSC Editor
The Message Sequence Chart Editor (MSC editor) is the graphical tool that is used
to edit Message Sequence Charts (MSCs). More advanced tools are visual modelling tool for analysis, specification, documentation and testing of communications
services and protocols. There are open source and commercial MSC editors.
MSCs are described in appendix A.

11.2.2 MOST Editor
Some OEMs maintain a database that contains the complete communications parameters of all bus systems of a car, including the MOST function blocks. They use
proprietary editing tools in this case. However, the MOST Cooperation has developed its own MOST Editor, which is described in this section.

11.2 Specification Tools 221

The MOST Editor can be used for creation and data management of function catalogs, also provided by the MOST Cooperation, in XML format. The function catalog contains the function blocks with all their defined methods and properties. The
individual description of the MOST device is based on this catalog. Those methods
and properties of the function block that are not to be implemented are deleted andthe value range of the existing parameters is adapted.
The actual user interface is divided into two parts (see fig. 11.3). The left side contains the function tree. It shows the individual function blocks with their functions.
The right side contains a detailed view of the functions.

Fig. 11.3: MOST Editor

The function tree can be extended or amended using the context menu that can be
activated by clicking the respective entry with the right mouse button. After selecting a function, its properties are shown in the left window.
The description of a function must have the following entries:







ID
Function class
SectionTextual description in HTML format
Available OPTypes (e.g., Get, Set)
Version information

222 11: Tools
Figure 11.3 shows the dialog for defining the operation types of a function. In theexample given, the function TimePosition of the function block AudioDiskPlayer
has the OPTypes Get, Set, SetGet, Increment, Decrement, Status and Error. In thenext step the parameters for each OPType are defined.
All parameters are stored in the XML function catalog containing the following entries [Cat 02]:

XML version



Function catalog header

Header of the current function block

List of the functions with their parametersDefinitions of the function classes

The following listing shows the basic structure of the function catalog:<?xml version="1.0" encoding="UTF-8" ?><!DOCTYPE FunctionCatalog (View Source for full doctype...)><FunctionCatalog><CatalogVersion></CatalogVersion><!-- FBlock: AmFmTuner --><FBlock><Function>….
</Function><Function>….
</Function></FBlock><Definition>…
</Definition></FunctionCatalog>

11.3 Simulation and Analysis Tools 223

11.3

Simulation and Analysis Tools

Simulation and analysis tools are a set of tools for the development, testing andanalysis of MOST networks using a consistent Graphical User Interface (GUI). At
the beginning of the development process, they are used to create simulation models
that emulate the behavior of the MOST nodes. During the development, these models serve as a foundation for analysis, testing and integration. The tools should support the following functions:

Online analysis of MOST network data enables data analysis in real time. Offline analysis, on the other hand, evaluates recorded data. Specific events can behighlighted or scoped based on the adjustments of the filter and trigger settings.
A time stamp synchronization of Viewer, Graph and Watch functions supports
the evaluation of data in chronological alignment.



A stress tool generates load on the Control and Packet Data Channel and applies modulated signal & lock sequences with precise timing.



A tool for the access to the hardware and network states such as light &lock, system lock and configuration status. Together with the stress tool, it
gives a statistic overview of the quality of transmission.

A Viewer for the Control Channel enables the analysis of CMS and AMS
protocols on a high level. It shows MOST events on the MOST ring.



An FBlock Viewer gives an overview of the application states that are communicated over the bus. It shows all or selected properties values transmitted
over the bus. It needs the XML function catalog for the disassembling of thevalues.



A Viewer for the Packet Data Channel should show the MOST High Protocol, MAMAC and MDP, depending on which of those are implemented. In
MOST150 systems, it should visualize the Ethernet channel. A transmitter
function sends packet data to other network nodes.



The tools should enable the access to the Streaming Channel. All synchronous and isochronous channels may be transmitted with 44.1 kHz or 48 kHz to
the PC or in the reverse direction from the PC onto the ring.



If the tool analyzes MOST slave nodes, it has to emulate TimingMaster, NetworkMaster and PowerMaster

The Central Registry stores all FBlocks that are available in the MOST systemwith node position address and logical address as well as the instance ID. A
viewer can show the FBlocks with the parameters and enable a comfortable access to the system.

224 11: Tools
11.4

Rapid Prototyping Tools

Rapid Prototyping Tools drive the development of MOST ECUs. You can choose
between the following types:


Network Services Library; It supports the software development and was considered in chapter 9.

Plug-in for Simulation and Analysis Tools



Hardware platform Rapid Prototyping and Evaluation

PC Tool Kit



System components

11.4.1 Plug-in for Simulation and Analysis Tools
These tools must provide a quick way to create control panels for MOST devices.
The panels serve to display bus signals in user-defined windows with graphic controls. Often, various controls are available such as text boxes, sliders, and pointerinstruments. The panel design may include static elements (text or frames), macros
as well as background graphics. Scripting languages enable the automatic executionof simulation, test and analysis functions.

11.4.2 Hardware platform for Rapid Prototyping and Evaluation
The hardware platform consists of the physical layer (oPhy or ePhy), an INIC for
MOST25, 50 or 150 and offers interfaces to the External Host Controller (EHC)and to the audio/video in- and outputs. Figure 11.4 shows the fundamental architecture of the platform. A Microcontroller or FPGA on board separates the Streaming
and Packet Data Channel as well as the Control Channel. It transfers the Packet
Data Channel and the Control Channel to a PC via USB and the Streaming Data toa codec. On the PC, the Network Service and an EHC application are running. A
MediaLB header could provide an interface for the MediaLB analyzer.

11.4 Rapid Prototyping Tools 225
MediaLB
Header

I2S

EHC
Service

USB

Network
Service

USB
Controller

I2C

CODEC

I2C

Microcontroller/
FPGAMediaLB
INIC

PhyInterfacePC

Line outLine inFig. 11.4: Architecture of a platform for rapid prototyping and evaluation

11.4.3 PC Tool Kit
PC tool kits often contain two components: a MOST Interface as well as a bundle ofmultimedia applications and MOST control functions. Figure 11.5 shows the architecture. The MOST Interface provides a high-speed connection between a PC andthe MOST network. It allows access to the Packet and the Streaming Data Channel
as well as the Control Channel and consists of the physical layer (ePhy or oPhy), an
INIC and the firmware. The interface to the PC could be PCI, USB or PXI.
The tool kits allow software development for devices and own tools without any
additional hardware.

Bus Driver

INIC
Phy Interface

Fig. 11.5: Architecture of PC tool kits

226 11: Tools
11.4.4 System components
For an effective system development, repeaters, hubs, gateways, and converters canbe used.
The repeater is a device that can act as a network extender or provide monitor-outfunctionality without interfering with the network’s structure. A hub recovers thesignals and distributes data streams in a star-like architecture. A gateways provides
interconnection from MOST to other networks such as CAN.
A converter converts network signals between different physical layers, e.g., between MOST50 electrical physical layer (ePhy) and the optical physical layer(oPhy). It is used to validate electromagnetic compatibility (EMC) and operational
electrostatic discharge (ESD) behaviors of a MOST50 ePhy Device Under Test
(DUT).

11.5

Hardware Development Tools

Each MOST ECU has got an INIC (older versions have a NIC) that can be analyzed
with two specialized tools. Those are the INIC Remote Viewer and the MediaLB
Analyzer.

11.5.1 INIC Remote Viewer
INIC Remote Viewer provides a detached gateway which is used to remotely analyze INIC-based MOST network node information. The viewer can provide the following functions:

Monitors properties and states of FBlock NetBlock and FBlock INIC, usually
only accessible through the Debug Header

Reads the INIC Configuration String

Visualization of:o

INIC parameterso

NetBlock parameterso

INIC states and state changesoPorts, sockets and connectionsoConfiguration string entries11.5 Hardware Development Tools 227

11.5.2 MediaLB Analyzer
The MediaLB Analyzer allows observation and visualization of MediaLB data andprovides following functions:

Disassembly of INIC Port Messages

Filter and trigger definitions

MediaLB lock and speed detectionSpeed modes for MediaLB 3-Pin and 6-Pin

MediaLB frame and physical channel counterMediaLB link layer protocol check

228

229

12

Compliance Tests

12.1

Objectives of Compliance Tests

As already explained in chapter 11, the integration of network systems and modules
is particularly challenging due to their complexity. An effective measure for meeting the challenge is to introduce a certification test process (Compliance Process) sothat the devices and modules are tested before they are integrated into the system.
This considerably increases the quality and reduces the complexity of integration.
It is the primary aim of the MOST Certification Test Process (Compliance Process)to test the modules and devices with regard to their conformity with the specification [ISO 9646] [ETS 300 406], i.e., whether the requirements of the specification
were met. The aspect of quality is closely related to the aim of reaching a high levelof interoperability.
The Compliance Tests cover a legal aspect within the MOST Cooperation. The
tested device is only allowed to participate in the MOST IP (Intellectual Property)
pool and to use the MOST® trademark (see fig. 12.1) after the compliance tests are
passed.

MOST Cooperation IP Pool
Royalty Free Cross Licensing
between Members

Membership
License to Use
Necessary IP
in MOST Specs

Royalty Free
MOST License(if compliant
to MOST Specs)

Implementer of
MOST ProductFig. 12.1: MOST IP and Compliance Process

In accordance with the layer model, the Certification Test Process covers the following areas (Compliance Levels) (see fig.12.2):
Module tests on the Physical Layer (e.g. FOT, Pigtail)(Full Physical Compliance)

230 12: Compliance Tests


Device test on the Physical Layer(Limited Physical Compliance)Device test on higher communication levels(Core Compliance)Device test on the Application Layer(Profile Compliance)

Fig. 12.2: Compliance Levels

12.2

Organization of the Compliance-Process

12.2.1 Authorities for the Compliance Process
Several authorities were installed to work together on the Certification Test Process
within the MOST Cooperation (see fig. 12.3). The MOST Compliance Supervisory
Board (MCSB) is responsible for controlling and supervising the entire process. It
authorizes the MOST Compliance Administrator (MCA) to supervise the Test
Process. He accepts the test reports from the MOST Compliance Test Houses,
checks them and finally grants the certificate.

12.2 Organization of the Compliance-Process 231

Fig. 12.3: Organization of the Compliance Process (source: [ComReq])

The performance of the Compliance Test is effected by MOST Compliance Test
Houses (MCTHs) approved by the MOST Cooperation. They are accredited according to the ISO 17025 General Requirements for the Competence of Testing andCalibration Laboratories by the German Accreditation Body for Engineering(DAkkS- Deutsche Akkreditierungsstelle GmbH) in Berlin /Frankfurt, Germany.
The test specifications, errata, as well as the technical consulting are effected by the
MOST Compliance Technical Group (MCTG) – a board of experts in which the test
houses are represented.

12.2.2 Workflow of the Compliance Process
The workflow of the certification test is carried out in three steps:
Step 1
The manufacturer selects a MOST Compliance Test House (MCTH) and develops
the test plan together with the test house. For that purpose, the manufacturer has tomake all documents required for the test available to the MCTH.
Step 2The MCTH carries out all necessary tests and writes the test report as well as manufacturer’s declaration, the Declaration of Compliance (DoC), which is to be added
to the Compliance File.

232 12: Compliance Tests
Step 3The MOST Compliance Administrator (MCA) checks the Compliance File and lists
the product, upon application by the manufacturer, as a MOST Compliant certified
product in the MOST Compliance Product List (MCPL). Thus the manufacturer isgranted the MOST license.

Figure 12.4 gives a survey of the workflow of the Compliance Process.

Fig. 12.4: Workflow of the Compliance Process (source: [ComReq])

12.3

Physical Layer Compliance Tests

With regard to the Physical Layer Compliance, the measurement principles and themeasurement methods were defined first, as well as the tolerances on which thetests were to be based. Within the scope of MOST Compliance, there are test points
SP1 to SP4 (see fig. 12.5 and chapter 6).
In the second step of the Compliance Process the procedures to be carried out (testcases) were defined. They indicate voltage and temperature ranges for which thefollowing measurements at test points SP1 to SP4 are to be carried out in particular:

Bit rate

Logical levels

Rise times



Pulse width variation and distortion

12.3 Physical Layer Compliance Tests 233

Fig. 12.5: Example of a test setup for the Physical Layer Compliance (EOC – Electrical/Optical-Converter; OEC – Optical/Electrical-Converter) (Source: [ComPhyLP 1.0])

Data-dependent and uncorrelated jitter

Input resistance and capacity



Wave length determination



Optical output power

ExtinctionPositive and negative overshoot behavior



Signal ripple
Temperature
OpticalPower Meter

Device under Test

Oscilloscope

High-speed
OEC

SP2
EOC

MOST
Test-Signal
Generator

IN
OUT

SP3
Attenuation

OEC

Fig. 12.6: Test setup for the Limited Physical Layer Compliance Test

NIC
or
INIC

234 12: Compliance Tests
The Limited Physical Layer Compliance Test aims at testing complete devices andcan be considered as a Blackbox test, since only test points SP2 and SP3 can betested. Figure 12.6 shows the setup for the Limited Physical Layer Compliance
Test. For MOST150, the Physical Layer Stress Test Tool is applied.

Spy

(a)

el. Wake-up

MOST

Tester

DUT

MOST

Spy

A

Power
Supply(adjustable)

el. Wake-up
Switch
MOST
MOST

MOST
a

a

b

b

MOST

Tester
1

MO ST

(b)

MOST

DUT

A
I

Power
Supply(adjustable)

Tester2

Fig. 12.7: Test setup with one (a) and two (b) testers for Core Compliance Tests

12.4

Core Compliance Tests

Based on an analysis of the MOST Specification, the requirements (specification
points) for the Core Compliance Tests were determined and the test cases were
written. These test cases verify the following behaviors:

Wake-up behavior-

Wake-up – TimingMaster-

Wake-up – woken up TimingSlave-

Wake-up – waking TimingSlave

Normal behavior (Normal Operation)

Power Management



Error Management



Ring Break Diagnosis

12.4 Core Compliance Tests 235

System Configuration-

Initialization (NetworkMaster)-

System Configuration (NetworkMaster)-

System Configuration (NetworkSlave)

Node addressingControl-Messages (Ack/Nack-Test)



Notification matrix

Segmentation of messages

Figure 12.7 gives an overview of the necessary test setups. The upper part of the
figure (a) shows the simple setup with one tester, the lower part (b) shows the setup
with two testers, by means of which the behavior in the ring can be simulated:

DUT inSleepModet_test :=t_wakeup

generate
wake-up event

start t_wakeup(max)

t_test := t_wakeup(receiving MOST
signal) or (timeout
t_wakeup)?

no

yes

t_test <t_wakeup_max?

no

yes

DUT ok

DUT not okFig. 12.8: Test caseSignal On Test

236 12: Compliance Tests
It is often necessary to support the workflow of the tests with function block EnhancedTestability (ET), which acts as a “filter” between the application and the
MOST Network Interface Controller and can be triggered by various events. It features the following characteristics:


It is located between the application and the NetInterface, it is mandatory foreach device or each MOST node and must not have any effect on the overall
device behavior. This applies in particular if the device is not under test conditions.



It generates or suppresses signals.



The FBlock is only available in the NetOn state and does not store any values
about a power failure.

Typical functions of the FBlock ET are, for example, AutoWakeup, NetInterfaceState, SendMessage, EchoMessage or Reset.

Figure 12.8 shows an example of the workflow of the test case Signal On Test.

12.5

Profile Compliance Tests

Profile Compliance Tests cover, as seen in figure 12.2, the individual applications(profiles), such as the ConnectionMaster. Figure 12.9 shows the setup of the Profile
Compliance Tests. They make use of the general structure of the profiles (function
blocks). Since the FBlocks are derived from the generic FBlock template GeneralFBlock, the parts of the FBlocks that are to be tested generically are also described in a high level MOST Profile Compliance Test Specification.
MOST Profile
Compliance Test
Specification

MOST Profile
ConnectionMaster
Compliance Test
Specification

MOST Profile....
Compliance Test
Specification

MOST Profile....
Compliance Test
Specification

Fig. 12.9: Structure of the Profile Compliance

Distinctive features and the dynamic behavior, in particular, are tested in the profile-specific test specifications derived from the FBlocks.

12.6 Interoperability Tests 237

Figure 12.10 shows the example of a Message Sequence Chart (MSC) used to describe a test case (“SyncConnectionTable_Get”) for the Profile Compliance Test.
The test cases specified in this manner serve as a basis for the MOST Compliance
Test Houses (MCTH) and for the test tools described in section 12.7. The tests defined there, based on the abstract test specifications, must still be implemented.

12.6Interoperability Tests

Interoperability Tests are defined as functional tests with respect to other functional
MOST products. Interoperable MOST products in the field are meant to increase
the user’s trust in the MOST system. This is why the MOST Compliance Process
calls for Interoperability Tests.

238 12: Compliance Tests
Profile_ConnectionMaster_Compliance_Test_Specification
msc Test_CM_SyncConnectionTable_Get

Initiator_Tester

Source_Tester

Sink_Tester

Result := DUT ok

Result := DUT ok

Result := DUT ok

ConnectionMasteralt
IF CM supports SourceConnect mechanism
Test_CM_SC_Connect
IF CM does not support SourceConnect mechanism
Test_CM_Allocate
t_1[t_Property]

SyncConnectionTable.Get

exc
t_1
Result := DUT not ok (1)SyncConnectionTable.Status(ConnectionList=_)exc
ConnectionList does not containconnection from "Source_Tester"to "Sink_Tester"
Result := DUT not ok (2)alt
IF CM supports SourceConnect mechanism
Test_CM_SC_DisConnect
IF CM does not support SourceConnect mechanism
Test_CM_DeAllocate
t_1[t_Property]

SyncConnectionTable.Get

exc
t_1
Result := DUT not ok (3)SyncConnectionTable.Status(ConnectionList=_)exc
ConnectionList contains
connection from "Source_Tester"to "Sink_Tester"
Result := DUT not ok (4)Fig. 12.10: Example of a Profile Compliance Test Case (SyncConnectionTable-Get)

In order to make sure that Interoperability Tests are reproducible and can be carriedout consistently by all manufacturers, a set of products has been defined for conducting Interoperability Tests. These products are referred to as Golden MOST Implementations (GMI) and are registered in a corresponding list. The devices to be
used for a test depend on the functional usability of the products.

239

13

13.1

Testing MOST based Infotainment
Systems
Challenges in Testing MOST Systems

The integration of modern and powerful infotainment systems, which today arelargely based on MOST, results in considerable challenges for the OEM which, inturn, influence the way in which the systems are tested. Typically, different suppliers deliver their respective MOST components to the OEM, where they are assembled into a complete system.
While developing the components, the suppliers employ various, in-house development processes, technologies and standards. The OEM then has the task of integrating the components and ensuring that they interact correctly within the context
of the overall vehicle system. Some important system functions can only beachieved through the cooperation of a number of components. An example for sucha function is accepting an incoming hands-free phone call while a music CD is being played: as soon as the phone call reaches the car, the music CD is paused andthe audio amplifier reallocates the audio channels to enable a hands-free phone callby means of microphone and loudspeakers of the sound system.
Due to the complexity of the systems involved, integration often has to start before
the components and the software are fully developed. In addition, the integrator has
only limited interfaces available by means of which tests can be controlled and supervised – typically only the external interfaces of a component, such as MOST,
CAN, etc. If errors occur during later integration phases it is usually difficult to assign these errors to a specific component so that a respective change order can beplaced with the appropriate supplier. This chapter describes the test process fromthe OEMs’ point of view. The following section gives an overview of the test activities of the OEMs in the context of the V-Model. Section 13.3 describes a generictest process used for all integration phases. The integration phases are explained in
the following sections. They are categorized into:component test,

integration test andsystem test.

Section 13.7 gives a survey of test tools.

240 13: Testing MOST based Infotainment Systems
13.2

Overview of the OEM Test Activities
Risk
Analysis

Requirements
Analysis

System Delivery

Test Planning

System Test

System Design
Specification of
System Tests

Definition of
System Architecture

System
Acceptance Test

Integration

Integration Test

Specification ofIntegration Tests

Detailed Component
Tests

Component Design
Specification ofComponent Acceptance
Tests

OEM
Supplier

Detailed
Component Design

Implementation

Component
Acceptance Tests

Component Tests

Legend:Design and Integration Phase
Test Phase

Fig. 13.1: The V-Model (source: Daimler AG)

Figure 13.1 shows an interpretation of the V-Model that describes the allocation ofdevelopment activities between OEMs and suppliers. The requirements on the overall system are defined first. This results in a system design, which identifies, among
other things, the various components of the system. The requirements on the individual components are distributed to the suppliers in the form of a component requirements specification. The detailed design, implementation and test of eachcomponent are then carried out at the supplier. The delivered components are subsequently accepted by the OEM by means of component acceptance tests and thenintegrated step-by-step into the overall system. Integration tests check the correctinteraction of the components. The basis for the integration tests is the interoperability specification, which is defined during the specification phase. During eachtest phase, the following quality characteristics are checked:Compliance with the functional specificationRobustness and fault tolerance

Performance and stability

The planning and specification of the tests can begin as soon as the requirements
have been defined.
The introduction of the MOST Compliance Process (see chapter 12) has influenced
the development process at the OEMs in the following manner: The MOST
behavior of a component is currently specified in terms of a reference to the MOST

13.3 The Test Process 241

standard and the specification of additional OEM-specific functionality. The
increasing harmonization between the OEMs will result in a reduction of the OEMspecific functionality as more and more elements of the requirements specification
are replaced by references to the standard or OEM defiend Test Specifications, likethe Automotive Application Recommendation. The OEM can then significantly
reduce the amount of in-house testing and expect fewer problems during the
integration of the MOST system. As a result, the OEM can focus on confirming theOEM-specified functionality.

13.3

The Test Process

In each test phase (component test, integration test, system test) a number of activities are systematically performed.

13.3.1 Risk analysis
Risk analysis is used to identify potential risks and problems related to the MOST
system under development and, if necessary, risk-minimizing measures in the architecture are defined. In addition, the risk analysis influences the planning and prioritization of the quality assurance activities during the development process. As partof which, the test plan defines the focus of the test activities. The test plan consistsof the identification of the objects to be tested, test goals, methodology for reaching
the goals, resource planning and supplier management. In the course of the following test activities, the test plan is successively refined into executable test specifications.

13.3.2 Test design
During test design, tests that were defined during the test planning phase are systematically refined into a number of test cases. The test design phase aims at defining a number of abstract test cases. The test cases specify the tests in such a mannerthat they can be understood by an application expert who is not familiar with the details of the implementation. If possible, the test cases should be reusable for numerous releases of the test object and possibly also for a number of different test objects
which share common properties. By describing the tests in an abstract manner (e.g.,
at the same level of detail as the requirements specification), they can be reused
more easily. A systematic approach should be applied when selecting test cases toensure that the test goals are adequately covered (e.g., the classification tree method[Lehmann 2000]).

242 13: Testing MOST based Infotainment Systems
13.3.3 Test implementation
During test implementation executable test cases are implemented on the basis of
the abstract test cases. Specific values for the test input data and the expected results
are, if not already defined, selected at this point of time. If the test cases are to be
carried out manually, the test case describes a sequence of actions to be performedby the tester in natural language according to a predetermined format. The sequence
unequivocally defines the steps to be followed during the test. If the tests are to be
carried out automatically (see section 13.7), the test cases must be programmed or
generated automatically. In this context, the systems required for executing the tests
must also be prepared.
The starting point of the test execution depends on the release of the object to betested. For that reason it is useful to complete as many of the test preparation activities (planning, design and implementation) as possible, before the test object is released for the test. As soon as the test object becomes available, the tests can thenbe carried out without further delay.

13.3.4 Test evaluation
During test evaluation the results of the tests are evaluated and an assessment ismade as to whether the goals defined in the test plan have been achieved. In thecase of failed test cases or of deficiencies in the tests themselves, some or all phasesof the test process may have to be repeated. The results of the test evaluation are
documented as a part of the summarizing test report and issues in the test object
discovered by the tests are entered into an error tracking system.

13.3.5 Test management
Test management is responsible for the correct application of the test process andfor ensuring that the aims associated with the process are achieved. Test management also has to accomplish a number of other tasks. It provides a contact person
for in-house (test team) and external issues (acquirer, project management, suppliers, quality assurance), it organizes and moderates reviews of test artifacts, supervises the cooperation with suppliers and is heavily involved with test planning andsystem acceptance activities.

13.4

Component Tests

Although component tests are already carried out by the suppliers, the OEM also
performs a component acceptance test of his own. This is to ensure to the highest

13.4 Component Tests 243

possible extent that the device meets the requirements of the component specification before system integration. The focus of the component test varies depending on
the development status of the device.

Fig. 13.2: MOST Physical Layer architecture (source: [ComPhyLP 150])

The test of the optical modules is an important aspect of this test phase. The
FOT/Pigtail modules, referred to as EOC (Electrical/Optical-Converter) and OEC(Optical/Electrical-Converter) in figure 13.2, are tested within the MOST Compliance Process (see chapter 12) for conformity with the specification. The test is particularly carried out between the specification points SP1 and SP2, as well as between SP3 and SP4 (see chapter 6) [MOST 2003]. The OEM tests the correct integration of the module within the device. It is important to verify that the input signals of the FOT lie within the specified range. Typically occurring problems thathave to be tested for are, for example, an incorrect peripheral circuit of the FOT, reflections if the PCB-connections between NIC and FOT are too long, or attenuations due to excessive bending of the Pigtail fiber in the device.
Further tests concern EMC interference caused by other modules (such as GSM
modules) and interference of other modules in the vehicle caused by the
FOT/Pigtail module itself (due to the plastic opening of the MOST connector in thedevice housing). In order to be able to carry out measurements of the output signal,a signal is usually generated by the NIC in normal operation and measured at SP2.
In a random test it is expected that there is enough buffering between the measured
signal and the predetermined tolerance limit to compensate for quality variations inlarge-scale production, and for ageing and temperature drift. Latter is documented
within the physical Layer compliance Test.
The OEC is additionally tested at the input of the control device. A MOST conforming optical input signal is applied to SP3 and passes through the entire specified optical power range (-2 dBm to -23 dBm). A signal lock must be available
across the entire range of the optical input power, in order to identify possible errors, such as increased pulse width distortion (PWD) when the amplification of the
optical receiver in the intermediate ranges is switched. In order to check the timing

244 13: Testing MOST based Infotainment Systems
parameters at SP4, worst case input signals are applied to SP3 by means of a test
device and are measured by means of an oscilloscope.

A particular challenge in testing the MOST Physical Layer is in the test setup. Active probes with a very small input capacity are required, as well as a wideband oscilloscope. It must also be ensured during the tests that no undesired side-effects arerecorded, such as line reflections due to the measuring setup. In addition, the ringarchitecture of a MOST System is a challenge because devices have to be measured
within a closed ring.
An essential part of the component test is the testing of the MOST Network Management functionality. The tests distinguish between the component-under-test being the NetworkMaster or a NetworkSlave. The start-up of the device, the queryingof device information and FBlocks as well as the shutdown are tested. It is important for further tests that the device shuts down correctly as this is the prerequisite
for carrying out several automated tests successively where each test assumes thatthe device is in a specific state.
Additionally, functions such as ring break diagnosis, automatic repeated transmission (low, mid and high-level) and temperature management are tested. For thetemperature management, the tests are carried out in a climate chamber, where exact and repeatable variations in temperature can be tested.
For component testing, especially for core compliance testing, the temperature issimulated by the FBlock ET. This method is easier and shorter than setting up thedevice in a climate chamber.
An important characteristic of a MOST device that is to be integrated in the overallvehicle context is its resistance to power supply variations. The static undervoltage
test checks the behavior at specific constant voltage thresholds (e.g., whether a shutdown is carried out or whether the function is restricted). For dynamic undervoltage
tests, the voltage is varied and the device is tested to see in which range the variations can be compensated.
The component acceptance tests are often made available to the suppliers so thatthey can reproduce the errors found during the acceptance tests. For that purpose
the suppliers do not only need the test scripts, but also all the relevant tools, databases and documentation required to perform the tests.
Particular challenges in the testing of the network management layer are the automation of the power supply by means of controllable power supplies and thechronological accuracy of the simulations and measurements.
Due to the functional complexity of modern infotainment systems, it is increasingly
important to ensure interoperability and functionality of the control devices as early13.5 Integration Tests 245

as possible. It frequently happens, however, that not all control devices are simultaneously available for implementing a cross-system function. This is why the interoperability in a component test is often first tested on the basis of remaining bus
simulators and test systems. The aim is to provide a system environment sufficient
to enable the effectual testing of the MOST functionality of the device. Examples offunctions of such a test environment are the provision of a MOST NetworkMasterand FBlock Controller to address the function blocks which are to be implemented
into the device.

13.5

Integration Tests

The focus of the integration tests is to ensure the correct interoperability between
the different MOST components. This integration step is often carried out underlaboratory conditions on customized test boards offering easy access to all interfaces required; this enables the quick set-up and integration, and the flexible use of
test and monitoring tools.
Network management functions, such as resource and connection management, diagnosis and software download can often only be tested in the integration test
phase, as the functions depend on several devices that cannot be simulated without
significant effort. A generic FBlock test is also carried out in this phase. This automated test queries each FBlock in the device to check whether all specified functions are implemented and behave according to the MOST Core Compliance Test
Specification [Core]. For example, it is tested whether the correct error codes aresent back in the case that an incorrect OPType is addressed or the parameter limits
are exceeded.
The dynamic behavior and the interoperability of the different function blocks are
specified on the basis of Message Sequence Charts [Z.120 99] (see appendix A).
The manual design, implementation, execution and assessment of tests of one Message Sequence Chart alone can take several days. The use of a formalized specification language, such as MSC, enables the automatic generation of tests which can
reduce this effort considerably and allows a more elaborate test than before. To derive executable tests from the MSCs is, however, not as easy as it might appear atfirst sight and requires the following process steps.
Defining the test interface: The specification describes the cooperation of all
FBlocks in the system. Depending on the integration phase, certain FBlocks or
FBlock Controllers will not be available in the system for a specific test. In order tobe able to execute a test fully automatically, at least one device in the system mustbe simulated. In integration tests, the user pressing the key, for example, is often
simulated. In component tests, at least those devices communicating directly with

246 13: Testing MOST based Infotainment Systems
the components to be tested have to be simulated. The test interface defines which
components are to be tested and which components are to be simulated.
Modeling the test behavior: After the above described test interfaces have been
identified in all MSCs to be tested, the resulting specifications are combined into
one complete model. Alternative paths that are distributed over several MSCs are
combined and references to other MSCs are resolved. The relationships between theindividual MSCs required to build this complete model are often specified by additional High Level Message Sequence Charts, from which the individual test sequences can then be deduced.
Generation of test data: The messages in the MSC specifications often contain parameters which can change during runtime. A typical example is the parameter telephone number in a message describing the status of a telephone call. It is importantwhen simulating such messages in a test environment to use concrete values. The
selection of these values can have a great influence on the test. If, for example, thetelephone number already exists in the address book, the name of the caller should
be indicated. A systematic approach is required, not only to identify the relevant test
sequences but also to identify with which parameter values the sequences should beexecuted.

Further challenges with regard to the integration testing of MOST systems are,among others, the test of non-specified system behavior (usually error cases) andthe test of the many different possible system configurations (e.g., based on combinations of optional extras, country variants, etc.).
Concretization of tests: In order to execute the test cases, they have to be provided
with much system-specific information not contained in the specification for reasons of abstraction (e.g., the node position address of the individual devices in thering). A concretization step is thus necessary to generate executable test scripts
from the test descriptions.

13.6

System Tests

During the system test, the MOST components are integrated and tested in the context of the final vehicle system. The focus of the system test is to test the interoperability of all MOST components and other vehicle systems (such as electrical system, CAN buses, etc.) and the stability of the individual components under “reallife” conditions. It is a particular challenge to systematically cover as many situations as possible that cannot be tested under laboratory conditions. For example, unfavorable combinations of different operating conditions, which do not often occur
in the field but could still lead to critical malfunctions. In this case, it is importantthat the causes of the error can be repeated later under controlled conditions. In thiscontext, data logging tools are often used (see section 13.7), which can record and13.7 Test Tools 247

analyze the entire bus communication. Usually, a large amount of data is generated
by such tools and must be limited by using filters and trigger conditions while taking care that the relevant data still remain intact. Another problem in carrying out
system tests is the chronological synchronization of the different bus systems sothat the reaction of the MOST bus to messages from other buses (e.g., the serial
connection to the GSM phone) can be reproduced. In order to identify causes of errors it may be necessary to also influence the MOST physical layer in the vehicle(e.g., to reduce signal power in a particular section of the MOST ring).

13.7

Test Tools

Test environments and test tools are necessary for different test activities to ensure asystematic, efficient and repeatable test. Standard, off-the-shelf test tools only support parts of the entire test process. For this reason, a tool suite is required, consisting of a combination of commercial and proprietary tools and adapted to the individual requirements of the OEM-specific processes. When using test environments
and test tools, it must be ensured that they are technically mature and that their use
does not lead to error reports which are not related to the actual test object. Thissection gives a survey of the test tools relevant for the test of MOST systems.
Test Management Tools such as TestDirector [Mercury] support test planning andtest traceability. Requirements can be imported and referenced during the definitionof test cases. In this way, test results can be directly assigned to the relevant requirements. Test management tools often also include defect management functionality. These functions support the management of defects that were found during thetests and the tracking of the elimination of these defects. Test management tools
also provide functions for summarizing the results of the test process (number oftests carried out, number of defects not yet eliminated, etc.) in the form of charts orreports so that they can be used in reporting the quality of the system to project
management.
Tools for the automation of test execution activities can be roughly divided into twogroups: Tools that are responsible for monitoring and recording the MOST behavior
on the MOST bus (Tracing Tools) and tools that send specific stimuli to the test object on the basis of predefined scripts and compare the reaction to the expected
MOST signals. Both types are often used together to obtain as complete a picture as
possible of the behavior under test.
Important characteristics of MOST Tracing Tools are, amongst other things, thechronological exactness of the traces, the ability to decode recorded messages bymeans of the XML-based function catalog specification (in real time), the automaticcomposition of segmented messages, the monitoring of Packet Data and Control
Channel, the definition of complex trigger and filter conditions, as well as the248 13: Testing MOST based Infotainment Systems
access to the Streaming and Packet Data Channel. Some tracing tools canadditionally be used as data loggers for installation in the vehicle even without aconnection to the PC or laptop. Such tools are particularly well suited for systemtests, as they can easily be built into the car and can continuously log the MOST
Bus. Tracing Tools for MOST systems have been developed by SMSC [SMSC],
Vector [Vector] and Optitas [Optitas].
Test script-based Test Automation Tools for MOST are offered by GADV[GADV], Ruetz Technologies [Ruetz], and Vector Informatik [Vector]. The tools
do not only offer a MOST interface, but also the support of several vehicle-specificbus systems at the same time. Important characteristics of such tools are, among
other things, the clear evaluation of the test results, the chronological exactness ofthe system when the results are measured, and the ability to dynamically react to incoming messages.
The Testing and Test Control Notation (TTCN) is a standardized test technology.
The latest version TTCN-3 [ETSI 2003] was standardized by ETSI (ES 201 873 Series) and ITU-T (Z.140 Series). TTCN-3 is a very flexible, abstract and expressive
test specification language, which also has a graphical presentation format strongly
based on MSC-2000. This allows the description of integration tests at the samelevel of abstraction and in a similarly readable form as the specification. Therefore,
TTCN-3 can be a suitable means for specifying standardized tests in the future – inline with its origins in the standardization of Compliance Tests for telecommunication protocols. TTCN-3 also standardizes, besides the test language, the operationalsemantics of the language so that a uniform behavior of the test scripts in different
tools can be guaranteed. This would allow the exchange of MOST tests between
OEMs and suppliers without the use of a specific test tool having to be specified.
Some OEMs [Burton 2004] and MOST Test Tool manufacturers [Ruetz] have already examined TTCN-3 for its ability to meet the challenges with regard to thetesting of MOST systems.

249

14
Introduction of MOST150 in Series
Production
14.1

Application of MOST150

Various vehicle projects have used MOST25 technology; it is characterized by ahigh quality index and a strict focus on the requirements of automotive infotainment
systems. Over the years, expert knowledge was acquired along the process chain(development, quality assurance, production, and customer service) and the processes were established. With requirements towards car-based infotainment systems
becoming more challenging, for example, video transmission and Ethernet connectivity, MOST25 maxes out, in particular in terms of available bandwidth (see fig.
14.1). Consequently, the path was cleared for the third generation of network technology: MOST150.

Fig. 14.1: Bus load increase in Audi systems

As the logical continuation of existing MOST25 transmission technology, it offers
the following distinct advantages:

Six-fold bandwidth increase compared to MOST25 (see fig. 14.1)

Native Ethernet channel for transmission of IP data.
This allows flexible introduction of IP applications.



Isochronous streaming
Can be used to transmit video streams (MPEG transport streams, VideoOverMOST)

250 14: Introduction of MOST150 in Series Production

Reuse of MOST25 applications
MOST25 applications, which are in use in current infotainment systems, can be
adopted almost without modifications

MOST150 multi-channel network

MOST150 enables the parallel use of all the mentioned services (packet data transfer and time-synchronous streaming) within one bus system. Depending on the system design, the individual services can be dynamically assigned with different resources during run-time.

14.2

MOST150 technology evaluation

14.2.1 Requirements and evaluation structure
The precondition for the introduction of MOST150 is a level of maturity comparable to MOST25, that is, the proof of suitability for series production. Every OEM
will thoroughly test new technology before deploying it. If the subject is - as is thecase with MOST150 - the result of an evolution of an existing system, attention ispaid to the continuing use of present qualifications, systems, and processes. The
main focus, however, remains on improvements and new functions. Only when thecritical requirements are met and the quality of software, hardware, tools, and testing systems clear the path to series production, a switch in technology is feasible.
Figure 14.2 presents the layers that are affected by the migration from a MOST25
environment to MOST150. The changes range from the physical layer to the application layer. This creates a challenge in terms of structuring the evaluation projectso that a verification of all relevant elements becomes possible.
In the case of MOST150, the evaluation can be structured to include the following
work packages:
Physical Layer
This includes the verification of all relevant hardware components (POF, FOT,
Pigtail, INIC) and the corresponding electrical parameters.

Network Services/INIC firmware
These form the software interface to the MOST bus and have significant influence on performance and reliability.



Network management/power management
These functions, which are elementary to every network, are required for administration, wake-up and sleep behavior.

14.2 MOST150 technology evaluation 251

Fig. 14.2: Layers that are affected by the migration



MOST diagnosis
Verification of MOST diagnosis covers ring break diagnosis (RBD), Electrical
Control Line (ECL) which was first standardized with MOST150, and the new
diagnosis function “Sudden Signal Off / Critical Unlock” (SSO/CU) enables
detection of the originators of sporadic ring breaks and Critical Unlocks.

Fig. 14.3: Definition of use cases for the evaluation

 Use Cases
MOST150 will be deployed in different configurations and electronic control units.
To cover all MOST150 applications that are relevant to OEMs, use cases are
generated through abstract modeling. Based on actual application scenarios (e.g.,transmitting a title list from a media player to the head unit), the departments for252 14: Introduction of MOST150 in Series Production
networking and infotainment define combinations of INIC interfaces, network
protocols, and the corresponding data patterns (see fig. 14.3). The collection of use
cases makes it possible to verify all INIC interfaces (MediaLB 3-pin, MediaLB 6pin, I2C, SPI, I2S, and TSI), MOST protocols (CMS/AMS, MHP and MEP), andMOST channels (Control Channel, Packet Data Channel, Streaming Channel).


Tools
These are indispensible for series development of MOST150 components. Active tools and listen-only tools, as well as the integration into the test automation have to be verified.

As the preliminary consideration shows, a variety of requirements for the evaluationof technology regarding maturity for series production has to be taken into account.
Subsequently, the example of practical implementation in the Volkswagen grouphighlights one possible way of evaluation.

14.2.2 MOST150 reference platform
The multitude of requirements towards the technology evaluation demanded the establishment of two verification projects. The hardware of the first project, the socalled reference platform, consisted of a MOST ring with seven participants(evaluation boards), which included TimingMaster, NetworkMaster, and PowerMaster. The focus of this system was the verification under laboratory conditions of
all work packages that had been identified. The design of each evaluation board allowed, for example, switching MOST hardware through the use of easily exchangeable pluggable circuit boards (“daughter boards”) with INIC and FOT. Initially, theemphasis was on tests of the wake-up/sleep behavior, reliability, and bus diagnosis(RBD, SSO/CU). Furthermore, the system provided access to all INIC interfaces sothat the 72 previously defined use cases were completely executed on this platform.
Hereby, all relevant application scenarios for Audi and the Volkswagen group could
be verified. The third pillar was formed by thorough performance measurements ofall MOST channels and transmission protocols.
Due to its layout, the MOST150 reference platform is not suitable for vehicle deployment.

14.2.3 MOST150_InCar
The second system was used for prototypic MOST150 integration in the vehicle. Of
particular interest in this scenario was the influence of the car environment on
MOST150 communication.

14.2 MOST150 technology evaluation 253

Tests were conducted in the following areas:overvoltage, undervoltage - variation of supply voltage by the on-board electrical system simulator.



temperature stress - passing through different temperature profiles in the climate chamber.



wake-up/sleep behavior - automated waking of the vehicle’s buses in varying
time intervals.



test drives - verification of communication in a customer environment (check ofreceived patters for absence of errors)

Apart from these tests, MOST150_InCar included a reference implementation,
which served the confirmation of interoperability of different ECL transceivers andthe verification of ring break diagnosis.

14.2.4 Results of the technology evaluation
After performing and completing the evaluation, the following results - presented in
the same order as the evaluation structure - were obtained:Physical Layer
Verification of all relevant hardware for MOST communication was successful.
Parts availability for series development of components, which was investigated in parallel, was confirmed, as well.

Fig. 14.4: Control Channel optimization steps



Network Services/INIC firmware
Different Network Services and INIC firmware versions were verified in termsof performance, function, and reliability. Detected inconsistencies were resolved, which led to significant performance improvements in critical areas.

254 14: Introduction of MOST150 in Series Production
Figure 14.4 exemplarily shows the throughput on the Control Channel. Here,the implementation and trial of different optimization measures were performed; eventually through the implementation of the so-called Network Services “Optimization III”, the previous internally defined reference value waseven exceeded.
Network management/power management
To verify this functional area, several ten thousand wake-up/sleep cycles wereinvoked. Behavior was tested under conditions of network stress, voltage stress,
and temperature stress. On this broad statistical basis, a positive verification ofthis area could be achieved.



MOST diagnosis
Besides verifying ring break diagnosis, evaluation of the new features SSO/CU
and ECL communication rendered positive results. Hence, apart from the diagnosis of static interruptions, which was already defined for MOST25, now detection of short breaks and communication in the case of an error is uniformly
specified and available across OEMs.



Use Cases
The core of the technology evaluation is the testing of the relevant use cases.
These tests were conducted using different patterns (variation of packet size
and timing), where each pattern was applied for at least 6 hours. Based on morethan 4,800 hours of test execution, the successful evaluation of the application
scenarios was performed. As a byproduct, by means of these tests, the process
chain from supplier over implementer to tester and developer was checked forweaknesses and optimized. Thus, countermeasures for detected errors could be
provided faster through the corresponding communication paths, integrated,and subsequently re-tested. Such processes are of great importance for minimal-risk development.



Tools
The measurements that were undertaken in the scope of the verification projects
used tools that due to the novelty of MOST150 had to be newly developed. In anumber of cases this led to the problem that malfunctions had to be assigned tothe technology itself on the one hand or the implementation in the tools or themeasuring software on the other hand. A close collaboration with the manufacturers was required so that remedy could be provided for the errors that occurred in that domain.

14.3

Conclusion

The use of two platforms (MOST150 reference platform and MOST150_InCar) allowed to verify all elements that were affected by the migration from MOST25 to
MOST150, both under laboratory conditions and in road tests.

14.4 Outlook 255

All deviations of the base technology that were detected in the course of the evaluation could be corrected. Expectations regarding data rates, reliability, functions, aswell as availability and quality of parts, were met. Based on the findings resulting
from this evaluation, the transition of MOST150 into series production was made.
There still remains potential for optimization regarding performance and processorload, especially for applications that utilize the MOST High Protocol. These optimizations can be introduced into series projects by later updates of MOST Cooperation specifications and supplier software.
The gathering of expert knowledge that is connected to the evaluation project is ahuge benefit for further series development. Quality is boosted through the adaptation of the Network Services integration process, which was extended as follows:
After the release of new Network Services or INIC firmware versions, preliminary
integration is performed, followed by regression testing on the MOST150 reference
platform. Only when the tests have executed successfully, integration into the infotainment devices takes place.
This guarantees interoperability of different versions and specific configurations on
MOST system level.

14.4

Outlook

MOST150 provides—through bandwidth reserve and functions for connecting consumer electronic devices—a future proof infrastructure for infotainment networking.
Due to the technological advantages, MOST technology could in the future become
established in additional vehicle applications. A potential area is the field of driverassistance systems. The requirements of image processing and sensor data processing towards networking are showing parallels to the requirements in the infotainment domain:The complexity of image processing systems and infotainment system is comparable.



The transported data types (packet data and streaming data) exhibit great similarity.



Audio data and video data have to be transmitted time-synchronous and withminimal delay.

Further concept analyses can bring clarity to which extent MOST can meet the requirements towards topology and reliability of transmission.

256

257

15
15.1

MOST150 Migration
Introduction

This chapter presents two possibilities for migration from MOST25 to MOST150.
One of the proposed solutions for the migration is an evolution concept, where all
MOST25 devices are upgraded to MOST 150, using a special hardware interface.
The second proposed solution is the development of a specific bridge architecture
between MOST 25 and MOST 150. The MOST Cooperation favors the evolution
approach.

15.2

MOST150 Evolution Approach

When migrating from MOST25 to a MOST150 infotainment system directly, thisapproach is called the MOST150 Evolution Concept [Schr 01] [Schr 02]. The basicof that concept is the idea to upgrade all devices to MOST150 off the shelf byadopting the hardware and the system software of the respective ECUs. The advantage with regard to the wiring harness costs is that no changes are necessary to theestablished wiring harness of a MOST25 system, compared to the
MOST25/MOST150 Bridge Concept.

Fig. 15.1: Illustration of the MOST150 Evolution concept258 15: MOST150 Migration
15.2.1 Hardware Evolution
The aim of the Evolution Concept is to point out that it is possible to migrate an
ECU “directly” without the need for a redesign of the complete ECU’s hardware.
However, the precondition is that the respective MOST25 device, to be adapted to
MOST150, uses an INIC architecture. If so, the principle is similar to exchanging
the network card of a common PC as presented in figure 15.1.
The basic workflow when applying the concept is to remove the network interfacecard, and plug in and update the drivers for the new one. To speak in automotive‘MOST language’ that means to replace the MOST25 components, INIC and FOT,
by the new MOST150 components, compile the ECU software with the MOST150
Network Services and finally flash that firmware on the device.
However, unlike the consumer electronics world – using PCI network interface
cards for example – there is no compatibility between the MOST25 and MOST150
components with regard to the physical connector pinning. Hence, in order to realise the MOST150 Evolution Concept, a kind of MOST150 network interface card,
called MOST150 PhyBoard, is required:Fig 15.2: MOST150 PhyBoard (source BMW AG)

The PhyBoard includes the MOST150 FOT as well as the MOST150 INIC and allnecessary peripheral components, such as resistors, capacitors, crystal and so on.
The ports of the new MOST150 INIC (OS81110) are wired to 4 FFC (Flat Flexible
Cable) connectors. The pin assignment of these connectors was chosen by the author in a way that corresponds to the pinning of the MOST25 INIC (OS81050). On
this account, the PhyBoard can be connected one-to-one to the footprint of the
MOST25 INIC on the circuit board by the use of FFCs (Flexible Flat Cables).
Hence, the adaptation of an existing ECU is achieved as presented in figure 15.3.

15.2 MOST150 Evolution Approach 259

Fig. 15.3: MOST150 Evolution Concept workflow (source BMW AG)

The ECU to be adapted is opened and the MOST25 INIC, as well as the MOST25
FOT, are de-soldered from the PCB. Afterwards, the FFCs are soldered onto thefootprint of the INIC. Power for the PhyBoard is taken from the original PCB bysoldering cables to the footprint of the FOT. Next, the MOST150 PhyBoard can bemounted on the ECU’s PCB quite simply by the use of spacing rollers. Afterwards,
FFCs and the power cable are plugged in. In doing so, one gets a fully MOST150
enabled ECU prototype hardware. The only thing to be done next is to upgrade thesoftware with the new Network Services and flash the adapted ECU.
Figure 15.4 illustrates this concept. Several ECUs have been adapted to MOST150.

15.2.2 System Software Evolution
The FBlocks for NetworkMaster, NetBlock, ConnectionMaster, as well as relevant
functions from the GeneralFBlock template only have to be updated. The applications themselves stay untouched. However, a minimum MOST 150 feature set has
to be implemented. Following, a few examples of mandatory features are provided:The system has to support the new frame structure.

Functions from the FBlock bundle 3.0 replace functions in the current system.
The FBlock bundle 3.0 contains the GeneralFBlock, NetBlock, NetworkMaster,and the ConnectionMaster.

260 15: MOST150 Migration


The max. AMS telegram payload size was increased from 12 to 45 bytes. Consequently, the TelLen field becomes 12 Bits large, and now has the same sizeas the TelLen field in the MOST High Protocol.

The sample frequency no longer is in a range between 30 kHz and 50 kHz but
either 44.1 kHz or 48 kHz. 48 kHz is recommended.

“Mandatory” and “Extensions” ranges of functions are now combined in the“Application” range.

NetworkSlaves now respond with an unchanged list if the InstID cannot bechanged.
AMP 1

Display

Display

HMI
NAVI 1

MOST150

Control Unit

Rear
Unit 1

TV

Control Unit

Display

1 MOST150 adapted prototypes based on real MOST25 ECUs

Fig. 15.4: Principal MOST150 Evolution Concept set-up

Configuration.Status now uses Control=NewExt, which also provides the DeviceID.



Function classes were modified (Container, restrictions on the use of streams,
stream signals…).



If the Central Registry is “full”, that is, no new FBlocks can be registered, theNetworkMaster replies with Configuration.Status(NewExt, <empty list>). If
some but not all FBlocks can be registered, NetworkMaster.Configuration.Status(NewExt, <partial list>) is sent.

Beyond that, all implementations of MOST25/50 concepts have to be removed thatwere abandoned for MOST150. These are, for example:


MAMAC is no longer available. If MAMAC is used, it is replaced by Ethernet
over MOST in MOST150.

The SourceConnect/SourceDisconnect approach, which is specific to MOST25,
has been abandoned.



Secondary Nodes are not supported.

15.3 MOST25/MOST150 Bridge Concept 261



MOST High over Control Channel is not supported.

The “data link layer 48 bytes mode” is no longer required; however, the maximum payload may still be limited by device specific characteristics (e.g., used
I/O interface or buffer sizes).

The SourceHandles function is no longer supported.



Large updates to the Central Registry are no longer announced by sending
NetworkMaster.Configuration.Status(OK).

Additionally conditional and optional features have to be considered. Conditional
means, for example, if the system does not use the Packet Data Channel, there is noneed to support low level retries on that channel. Optional features are new
MOST150 features, for example, isochronous transfer was introduced, supporting
the use cases DiscreteFrame Isochronous, A/V Packetized Isochronous, and QoS IP.

Note: If you have to migrate to MOST150, attend to the latest revision of the Application Note MOST150 Migration from the MOST Cooperation [AppN Mig].

15.3

MOST25/MOST150 Bridge Concept

The second proposal, when migrating from the actual MOST25 infotainment system to a MOST150 based one, is the so called MOST25/MOST150 Bridge Concept.
That approach assumes that at first only the components with high bandwidth requirements are upgraded to MOST150. The other nodes continue to be MOST25
based. Obviously, two optical rings are required with this concept, linked by an additional new device, a so-called MOST25/MOST150 Bridge. Although the bridge
could be integrated in an ECU, e.g., the HU, this concept is cost-intensive and,hence, is not recommended.

15.3.1 General Bridge Architecture
The bridge device is intended to be used to connect a MOST25 network to a
MOST150 network, whereby streaming, packet and control data need to be routed.
Figure 15.5 gives an overview of the general bridge architecture.
Both MOST INICs (INIC_A and INIC_B) use the respective MediaLB interfaces[MediaLB] to connect to the EHC (Enhanced Host Controller). MediaLB (Media
Local Bus), or MLB, is a MOST specific high speed interface, providing full accessto the whole bandwidth of the MOST bus. For synchronous data bridging, the262 15: MOST150 Migration
INICs are linked via their I2S streaming ports, in order to transport the data content
of synchronous channels directly without the need of interaction of the EHC.

MediaLBMediaLBEHC

INIC_B

I2S

Device: 0x101

INIC_A

Device: 0x103

Device: 0x102

Device: 0x102

MOST150Subnet B

Device: 0x103

BridgeMOST25Subnet A

Device: 0x101

Fig. 15.5: General architecture of a MOST25/MOST150 bridge device

15.3.2 Addressing Concept
For seamless migration, it is essential that a common MOST device can be integrated into a subnet without change. Thus, the usual addressing method needs toremain unaffected by the bridge and the local addressing inside a subnet is not allowed to differ from the addressing found in today’s MOST networks.
A method for addressing a target beyond the bridge in another subnet had to be defined. A solution is quite obvious. As common MOST devices, so far, only makeuse of the three lowest nibbles (12bit) of the device ID, and ignore the four highest
ones, the idea is that the highest nibble (4bit), henceforth called SubnetID, of
MOST’s DeviceID should be used for subnet addressing. The message sequence
chart in figure 15.6 depicts how the source address and the target address are
mapped through the MOST25/MOST150 Bridge.
If a message, incoming from a subnet, is passed to the EHC of the bridge, the device addresses, respective SubnetIDs, need to be adapted before forwarding to the
opposite subnet as follows: Device 0x0101 of subnet A in figure 15.6 wants to senda request to device 0x0102 in subnet B. As the target device is located in the opposite subnet, it is registered by the bridge’s special NetworkMaster with DeviceID
0xB102 in subnet A. So device 0x0101 addresses its request to that ID. The bridge
processes that telegram by adapting source and target device addresses before forwarding to subnet B. SubnetID A will be added to the source address and at the15.3 MOST25/MOST150 Bridge Concept 263

same time, the highest nibble of the target address will be set to zero as it needs to
be in the local subnet. The response of device 0x102 of subnet B to device 0x0101
in subnet A is processed in the same manner.
Controller
0x0101Subnet A

MOST Bridge

0101.B102.FBlock.InstID.FktID.Get(…)
ACK
Subnet of source
B102.0101.FBlockID.InstID.FktID.Status(…)

Slave
0x0102Subnet B

Subnet of source
Always zero (local subnet)
A101.0102.FBlockID.InstID.FktID.Get(...)
0102.A101.FBlock.InstID.Status(…)

Always zero (local subnet)

Fig. 15.6: Message sequence chart description of the subnet addressing method

15.3.3 Network Management
It is essential that each subnet is managed by its own NetworkMaster. Therefore, a
network scan has to be done only within the local network. The configuration statesof all subnets are completely independent from each other. A change in the configuration state thereby is recognized in other subnets by broadcasting added or removed services.
The central registry of each subnet contains all MOST services found in the wholesystem. Services in the local network are stored with their ‘normal’ DeviceID (highnibble equal to 0). Services located in the remote subnet are stored with a DeviceID
in which the high nibble represents the subnet identifier of the appropriate network.
Therefore a device which requests the central registry always has the ability tocommunicate with the correct services without the necessity to use additional
mechanisms.
Figure 15.7 presents a proposal for a bridge from a network management point ofview. Here the bridge acts as NetworkMaster in both subnets. A constraint to thisconcept is that, if the bridge is not integrated into the head unit – as the head unit
recently normally is the master in a legacy MOST25 system – it will be necessary to
implement the head unit as a slave device.
However, the advantages of that ‘master-bridge’ concept are:
The validation of MOST service instances (FBlockID / InstID) can be done acrossall subnets. Therefore, it is possible to solve all address conflicts inside the bridge.

264 15: MOST150 Migration

Fig. 15.7: Network management bridge architecture
NWMS: NetworkMaster Shadow
NMW:
NetworkMasterIf exactly two subnets are coupled by a MOST bridge it is an advantage to implement both NetworkMasters inside the bridge. In this configuration a common instance may validate the registries of both subnets. So the pairs of FBlockID and InstID can be made unique over both subnets.
The ‘master-bridge’ contains the TimingMaster for both subnets to ensure that thesystem frequency is 100% identical. This allows the connection of the two INICs
directly via the I2S interface to transmit synchronous data between the subnets
without the need for buffering or sample rate conversion (refer to chapter 15.3.4).

MediaLB@ 48.0 kHz

CLK:

INIC_B

EHC

44.1 kHz FSY
44.1 kHz CLK
44.1 kHz DataMediaLB@ 44.1 kHz

INIC_A

CLK:
Crystal for 44.1
kHz Timebase

Crystal for 48.0
kHz Timebase

Device: 0x101

Device: 0x103

Device: 0x102

Device: 0x102

MOST150Subnet B @ 48.0 kHz

Device: 0x103

BridgeMOST25Subnet A @ 44.1 kHz

Device: 0x101

Fig. 15.8: Bridge architecture for bridging asynchronous sub-networks

15.3 MOST25/MOST150 Bridge Concept 265

15.3.4 PCM Data Bridging
If the system frequencies differ, either a sample rate conversion has to be implemented or isochronous transmission in the MOST150 network has to be used for thehandling of MOST25 synchronous data. Figure 15.8 illustrates a legacy MOST25
ring with 44.1 kHz and a MOST150 ring with 48 kHz. As MOST150 provides
isochronous capabilities, synchronous/isochronous data also can be linked using thestreaming ports.
In addition, the establishing of the synchronous connections in both networks via thebridge has to be considered.
For more information about the bridge concept, attend to the latest revision of the Application Note MOST150 Migration from the MOST Cooperation [AppN Mig].

266

267

16

Manufacturing and Processing of
MOST Components

The manufacturing process of devices with an optical MOST interface involves anumber of changes and amendments compared to the manufacturing process ofelectronic components without opto-electronic interfaces. These changes andamendments can be categorized into two groups.
On the one hand there are parameters which are influenced by the processing of the
opto-electronic components and their characteristics and which require particularmeasures compared to conventional electronics components.
On the other hand completely new processes and methods must be established for
manufacturing the opto-electronic MOST components, which are not used normallyin the manufacturing of electronic components.
Both aspects will be discussed in the following sections and the requirements withregard to the manufacturing process will be described in detail.

16.1

Structure and Testing of Opto-Electronic MOST
Components

The assembly of electro-optical (FOX, Fiber-Optic Transmitter) and opto-electrical(FOR, Fiber-Optic Receiver) converters, mechanical adaptations and, as the casemay be, fibers inside the device is represented by a pigtail. It depends on the respectively realized form of the product, whether the pigtail module must be treated as amechanical unit in the manufacturing process.
There are two basically different mechanical design concepts for pigtails. One comprises the group of flexible pigtails with a horizontal or a vertical fiber output. They
are connected to a connector by means of an external pair of fibers (here referred toas “set of fibers”). The connector is the optical MOST interface to the wire harness.
The distance between the fiber face end and optically active elements (PIN diode or
optical transmitter) must be kept as small as possible at both ends of the fiber.
The other structural concept comprises the rigid pigtails (with the product namesµPigtail or Minipigtail, for example), where no external set of fibers is used. The
FOX and FOR are integrated into a connector into which the optical plug-in connections at the side of the harness can be directly plugged.

268 16: Manufacturing and Processing of MOST Components
In this case, the connection between FOX or FOR and the plug-in connection of theharness is effected via short POF pieces, glass sticks or via lens structures for optically bridging the gaps.

Fig. 16.1: SMD FOT as complete pigtail header
solution as specified for MOST150

16.1.1 Header
In this context, a header is meant to be the mechanical entity comprising the following functional elements: optic-electrical conversion, lightguide alignment, lightguide fixture, EMI- and crosstalk shielding. The header may be an assembly of individual parts each providing one or more of these aforementioned functions. For
header products using FOTs in Through Hole Mount (THM) package technology
these sub-parts are typically the FOX and FOR, a required plastic adapter, the respective sheet-metal case and a holding fixture for the fibers.

Ferrule Holders
Sheet Metal Housing

Fig. 16.2: Rigid Pigtail without additional electrical contacts

In case of a rigid pigtail header, additionally there are optical interface elements
bridging the distance between the FOX/FOR and the plug-in connections of theharness. In exchange, the fixtures for the internal fiber set are dropped. Figure 16.1
shows a header in SMD package technology based on SOIC24 standard. For
MOST150, this SMD-package is specified in the MOST150 oPHY SubSpecification. As it includes all interfacing and holding elements for the device internal fiber set, as defined above, it is to be assigned to the class of headers.

16.1 Structure and Testing of Opto-Electronic MOST Components 269

In contrast to this, the ferrule adapters in the rigid pigtails serve for a direct contact
to the vehicle wire harness. Header and connector form one unit. Figure 16.2 shows
an example of the constructive design of a header in the rigid version. In this version there is no connection for an internal fiber set.
Functional Elements of a Header

Within the class of headers different technical solutions can be found on productlevel. Despite their actual technical realization they have to provide a set of functions. These functions can be realized by dedicated elements. Several functions canalso be combined into sub-components.
The main function of a header is to convert the data signal from the electrical into
the optical domain or vice versa. Therefore, opto-electronic semiconductors arebonded onto a leadframe or pre-molded leadframe. The leadframe, with attachedIC-dies, gets packaged by insert molding, using transparent mold compound or byopaque while relieving appropriate windows for the optical signal. For pre-molded
leadframes, a transparent globetop may be applied.
For FOR and FOX packaged separately, a dedicated component is used to mechanically support the FOTs and to fix them at a specific relative position. Some spacer
designs additionally take special care to restrict the position tolerance of the THMpins of the FOTs.
A mechanical interface structure, giving reference to the optical axis, is needed toenable sufficient alignment of the pigtail fiber or lightguide element. To ensure
good optical coupling—under all conditions and over lifetime—the fiber ferrule
must be fixed to the alignment structure. This fixture can be designed for repeatableattaching and deattaching of the fiber or for one time attachment. With the SMD
package, a clamp fixation is specified that holds the ferrule into its position when aspecific insertion force is exceeded. The pigtail fiber can be detached from theheader by pulling with a force exceeding the retention force.
An appropriate shielding may be required to guarantee EMI conformity. A shieldcase could additionally prevent electrical and optical crosstalk between receiver andtransmitter unit. In many header designs, the shield case provides the overall fixation and stabilization of the assembly.
Structure

By means of a suitable assembly process, the components are assembled in the
sheet metal case in such a manner that the FOXs or FORs in their target position are
fixed relative to the fibers or the optical path.
The actual alignment of the optical axes is not effected by means of the sheet metalcase or the plastic adapter, as their tolerances are too high. It is rather the cavity of270 16: Manufacturing and Processing of MOST Components
the FOX or FOR case itself which is used for alignment. In all constructions, theoptical waveguide extends into the cavity of the FOX or FOR. Thus it is possible todetermine the relative position towards each other of the converter and the fiber
face. The position tolerances only depend on the tolerances of the cavity and thewaveguide.
Testing

After the mechanical assembly and before the actual mounting, the headers are subjected to a performance and function test. In the test, system-relevant parameters(radiation power (FOX), timing parameters at low input power (FOR) and power
consumption) are measured and documented. This ensures that only good parts aremounted into a device.
Fig. 16.3: Pair of fibers for theinternal connection of the
MOST150 SMD header to the device connector

16.1.2 Set of Fibers
Depending on the design (flexible pigtail or rigid pigtail), respective sets of fibers
are used within a device. In contrast to the wire-set fibers, the internally used fibers
have a single coating and are thus considerably thinner (ca. 1.5 mm) than the harness fibers. A set of fibers consists of two POF fibers of a predetermined length
which have ferrules attached to their two ends. The ferrule geometry at the wire
harness end must comply with the MOST Specification- In contrast to MOST25,
the internal ferrules on the MOST150 SMD-header side are specified within the
MOST Standard, too. Thus, the fiberset and SMD-header are compatible independently form their respective manufacturer. For MOST25, the ferrule at the side of theheader can be designed differently depending on the manufacturer of the FOX or
FOR. Figure 16.3 shows such an internal set of fibers. On the one side one can see
the ferrules with the Standard MOST Interface, on the other side the ferrules withthe proprietary internal interface.
The internal ferrules are considerably smaller than the ferrules with the MOST
geometry. The length of the POF depends on the respective requirements of thedevice.

16.1 Structure and Testing of Opto-Electronic MOST Components 271
POF

The POF is cut into pieces of required length by means of a saw. The basic structureof such a separating device can be found in figure 16.4. Arrows in the sketch show
the direction of transport of the fiber.

Fig. 16.4 Structure of aseparating device for POF fibers

The POF raw material is delivered on a roll. The POF feed roll feeds the saw unit.
The fiber is deflected by a number of deflection pulleys to ensure constant tension
and avoid mechanical stress on the fiber. This reliably prevents the POF from being
damaged by the unwinder-sawing fixture.
It is, moreover, very important that the end faces of the fibers not be damaged orsoiled by the sawing process. Thus specific saw blades developed for that application are used in the sawing fixture. The blades have to be cleaned at regular intervals.
Besides the optical characteristics, the temperature stability is an important parameter for specifying the POF. The POF currently used in the wire harnesses of vehicles
is specified for temperatures of up to 85 °C. In contrast to this, the fibers used insidethe devices are approved for temperatures of up to 105 °C. Excess temperaturesduring processing which exceed the limiting values can cause deterioration of the
optical performance and are thus to be avoided by all means.
FerrulesThere are several different basic methods of attaching ferrules to an optical wave
guide. These methods comprise gluing, crimping or laser welding. The method used
determines the manufacturing process of the ferrules and the costs involved. For
standard MOST products, the laser welding process is used for connecting ferrules
and POF. With a high power short-pulsed laser both the black plastic coating of the272 16: Manufacturing and Processing of MOST Components
fiber and the surrounding ferrule material are melted. When they harden again, theferrule and the POF coat form a high-strength plastic connection. The crosssectional drawing of such a welded connection is shown in figure 16.5 (dashed ovalline). The actual welded joint is only recognizable due to the missing air gap.

Fig.16.5: Micrograph of alaser-welded ferrule

Pull tests have shown that it is generally not the welded joint itself, but the POF
coat which breaks. Figure 16.6 shows the schematic view of the structure of such a
welding fixture (welding unit with manually operated fiber feed).
In this machine, two fibers are processed simultaneously in order to improve thethroughput. Both fibers are welded to the ferrule in one step. The ferrules are fed tothe actual welding point from two rolls as an endless tape. The operator must insert
the fibers into the feeds of the fiber ends and start the welding process manually.

Ferrule-Tape
SupplyFerrule-Tape
SupplyFig. 16.6: Structure of a semiautomatic laser welding fixture

Fiber-End Supply

The plastic of which the ferrule is made must be suitable for laser welding. Currently only one material is known and available on the market. It is a polyamide 12,
which is sold in different versions under the product name Grilamid. It contains acertain percentage of glass and can also be colored without impairing laser weldability.
The manufacturing process must ensure that the fibers keep a defined backward
clearance of greater than or equal to 0 mm with regard to the end face of the ferrule.
This is necessary in order to reliably prevent a collision between fiber and16.1 Structure and Testing of Opto-Electronic MOST Components 273

counterpart. For MOST150, the clearance at the side of the header is defined by the
MOST150 FO-Transceiver (SMD-header) drawing to be 0.01 to 0.1mm behind theferrule endface. For MOST25, the clearance is within the scope of the respective
manufacturer. At the side of the connector, the MOST Specification defines thevalues -75 µm +/- 25 µm. A pin which is situated in the ferrule holding fixture of
the laser welding unit and advances by the corresponding value ensures that therequired clearances are kept with sufficient accuracy.
In general, one tries to keep the attenuation of a fiber as low as possible. There are,however, special cases in which a pre-defined optical attenuation must be introduced. This is ensured by way of an additional backward clearance of the fiber withregard to the end face of the ferrule. Compliance with the value of the backward
clearance is ensured by means of a pin advancing by a respective value in the laser
welding unit, analogous to the fibers with a standard attenuation.
The ferrules are delivered in rolls as an endless tape. Both welding and cutting areconducted on the laser welding unit, i.e., the ferrule is cut from the endless tape andthe burr is reduced to an admissible value.
Testing

If the sets of fibers are manufactured and processed separately from the header, it
must be ensured by special testing measures that their attenuation is not higher thana defined limiting value. MOST150 gives an attenuation limit of 1.5 dB for the pigtail fiber. Thus it is ensured that even a combination of a header with the worst
permissible performance and a set of fibers with the highest permissible attenuation
still comply with the permissible tolerances for output radiation efficiency and responsively according to the MOST Specification. Otherwise it would be necessary
to conduct an end-of-tape selection test for the overall layout of the set of fibers andthe header with regard to radiation efficiency.
In addition, random testing using a pull strength measurement setup must ensurethat the pull-off strength at the welding point is sufficient.
The values for the pull-off strength are found to be very constant. Additionally, themechanical stress is very low, in contrast to a vehicle wire harness.
With regard to the optical attenuation of the fiber pieces, the following influencing
factors are known or possible:Fresnel losses (~0.2 dB/end face, ca. 0.4 dB per connector)



Axial displacement of the fibers relative to each otherRadial displacement of the fibers relative to each other

Slanting position of the fibers relative to each other274 16: Manufacturing and Processing of MOST Components
Damaging of the cladding due to errors in the laser parameters and variations in
the thickness of the fiber coating

Optical quality of the saw face / condition of the saw blades

Fresnel losses occur at each transition from one medium to another. They add up to
ca. 0.4 dB per connector.
The maximum axial displacement is defined by the MOST Specification (connectorside) and by the manufacturer’s specification (header side).
A measurement setup in the laser welding device ensures that the value for eachmanufactured fiber be within the permissible mechanical tolerances.
The radial displacement results from the diameter tolerances of ferrule and fiber andfrom the maximum eccentricity of the POF coating.
The slanting position of the fibers relative to each other may result from a tilting
within the connector or from a slanting position of the fibers during the sawing
process. The latter is prevented by a correct setup of the sawing fixture. The first is
only very small for constructive reasons.
The wrong power setting of the laser in the welding unit in combination with unavoidable variations in the thickness of the coating can theoretically cause damage
to the POF cladding. This could result in higher attenuation.
Experience has taught that the condition of the saw blades is the one factor influencing the attenuation of the fibers that has to be supervised most closely during
manufacture. The other parameters are subject to only slight variations or can be
virtually neglected. As mentioned before, this is achieved by exactly defined maintenance intervals and the 100% testing of the fiber attenuation.
For determining the fiber attenuation, the insertion loss method according to IEC 61
300-3-4 is suggested by the MOST150 Measurement Guideline. The test setup iscalibrated periodically by measurement without DUT. The DUT’s attenuation is thedifference of the measured optical power with the DUT included and not included.
The substitution method according to IEC 61 300-3-4 is also used as testing methodfor determining the fiber attenuation. The test set up is calibrated periodically bymeans of a reference standard (Golden Fiber). This is a fiber with exactly definedattenuation capacities and structure. The underlying measurement setup can begathered from figure 16.7:

16.1 Structure and Testing of Opto-Electronic MOST Components 275

ModeMixer

Fig. 16.7: Basic setup for measuring the attenuation of a fiber

Fiber F to be tested is clamped into test contacts A, B in a calibrated measuring device and the measurement process is started. By using an attenuation measuring device, it is compared to a fiber with known characteristics. Thus the respective attenuation is ascertained.
The following apply for both measurement methods: The radiation is induced into F
according to IEC 793-1-1. The output signal of the FOX is conducted through amode scrambler. This ensures that there is the same angular distribution and intensity density allocation at its output as can be expected at the end of a “long” POF
stretch. This is necessary to ensure comparability of the measurement data gained
and independence of the radiation source used (dimension and geometry of thebright spot, angular dependence).

16.1.3 Connectors
A device is connected externally via the device connector/s to the wire harness. The
nomenclature (2+N and 4+N) used for the connectors indicates that they are suitable both for connecting electrical as well as optical signals to the respective device.
In order to ensure compatibility, the MOST Standard defines the interface geometry
towards the wire harness. The interior design of the device may vary, however. The
2+0 connector for MOST150 is an exception to that. Here the footprint and maximum dimension of the connector is defined within the physical layer specification.
Figure 16.8 shows a 2+4 connector for use with flexible pigtails. At the right edge
one can see the four electrical contacts. The two ferrule holes accommodate the
MOST ferrules.
2+0 connectors are usually only used with rigid pigtails, although a 2+0 connector
with a flexible pigtail would be possible. In contrast to this, connectors with opticaland electrical contacts are mostly implemented as flexible pigtails (see fig. 16.8).

276 16: Manufacturing and Processing of MOST Components
Consequently, all connectors at the device have electrical contacts – either the electrical connections of FOX and FOR, or any signal lines required within the MOST
component. Thus all connectors have to be run through the soldering process.

Spring fixationelectricalContacts

FerruleHoles

16.2

Fig. 16.8: 2+4 device connector

Processing within the Scope of Electronics Manufacture

Opto-electronic components are more delicate with regard to processing during soldering than other comparable electronic components. This is particularly the casewith MOST components if not only FOX and FOR but also the POF must passthrough the thermal process during soldering. The SMD-header for MOST150 was
specified to break up the pigtail into separate parts: one part is the header designed
for automated assembly, the other part is the pigtail fiber set that can be kept out ofthermal processes.

16.2.1 Mounting and Soldering of Headers
THM based headers

Headers based on FOR/FOX in THM packages are components that typically cannot be mounted by means of a mounting machine. They must be positioned manually before the soldering process. The header may be mounted by machine if it isguaranteed that the position of all THM-pins of the header is within the overall tolerance range of the PCB’s pinhole position and diameters without overlap. If thepigtail fibers are already premounted and are thus led through the soldering process,precautions have to be taken to avoid damage. With regard to the protection of thefibers and the handling convenience, it is better if the internal set of fibers ismounted only after the thermal process in the soldering bath.
For wave soldering and partial soldering the assembly is usually first preheated using infrared radiators on the soldering side. This is required in order to avoid
thermo-mechanical stresses. Temperatures of up to 100 °C are reached at the soldering side. The assembly then passes over the soldering wave.

16.2 Processing within the Scope of Electronics Manufacture 277

The housing and the pins of the FOX and FOR, as well as the sheet metal case of
the exterior shielding are heated up significantly during this process, even thoughimmersion into the soldering bath only takes a few seconds. A soldering bath has atemperature of 240 to 260 °C. If a lead-free soldering process is used, these values
are about 20 °C higher, because the lead-free solder has a higher melting point. The
FOXs and FORs used must be specified to be processed at such high temperatures.
Due to the structure and the optically transparent plastic material used, damages tothe assemblies may be caused by high thermo-mechanical stresses. The plastic material and the leadframe have different coefficients of thermal expansion. The heating of the material nearly reaches the glass transition temperature of the potting
compound used. In this range, the coefficient of thermal expansion changes considerably, which results in additional stresses. Unfavorable soldering profiles may
cause delaminations and debonding.
In the case of premounted sets of fibers, it must be ensured by measuring that thefiber end faces do not heat above the maximum temperature permissible for the optical wave guide. Characteristic damage patterns are concave vaultings at the fiber
end face. In such a case, the fiber attenuation rises significantly.
Usually, the transparent potting compounds used here are also hygroscopic. A typical humidity class of the FOTs is 2A. Long-lasting, unprotected storage should thus
also be avoided. If necessary, the components will have to be dried before processing.
SMD headers

The header package for surface mount technology, as defined in the MOST150
physical layer specification, is typically delivered within tape-on-reel. It can beprocessed by standard pick-and-place equipment as commonly used in electronic
assembly lines. The SMD-header is placed in a pocket of the packaging-tape which
is furled on a reel according to DIN EN 60286-3:2008-4. Typically, the SMDheader is delivered with a Kapton™ tape on top providing a flat and clean surface
for vacuum pick up nozzles. Thus it can be picked up and placed on the printed circuit board just like any other SMD component of similar size and weight.

16.2.2 Mounting and Soldering of Connectors
In line with the headers, device connectors are components that have to be positioned before the soldering process. That applies to both the standard connectors
with an optical interface and to µPigtails with and without additional electrical contacts. Due to their geometry, these components cannot be effectively mounted
automatically.

278 16: Manufacturing and Processing of MOST Components
The soldering of the standard connectors is not a critical process. They are passive
elements with a high thermal stability. Rigid pigtails have to be treated differently,
as was mentioned before with regard to the headers. In this case the FOXs andFORs used must be specified to be processed at the respective soldering temperatures. Both the plastic lenses and the short fiber pieces used for bridging the gap between the FOX or FOR and the set of fibers are exposed to high processing temperatures.

16.2.3 Mounting of Internal Sets of Fibers
There are pigtail types in which the internal sets of fibers are processed separatelyfrom the headers as it is standard by concept for the SMD header, and others inwhich the set of fibers and the header already form a unit when they are delivered.
The latter require specific handling for processing. The connection of the set of fibers at the end of the tape is, however, easier. If the set of fibers and the header are
mounted separately, the fibers are mounted at the header side and at the connector
side after the last thermal process. The holding spring for the ferrules at the connector side not only ensures fixture, but also the springing behavior required by MOST.
Previous to mounting the fiber on the SMD header side, the Kapton™ tape on topof the SMD transceiver needs to be removed. The fibers can then be plugged into
the respective cavity. To prevent mixing up receive with transmit path, the FOTcavities and fiber ferrules are coded by diameter. The cylindrical part and the flaring ring on the ferrule, both contribute to the coding. Their diameters are inversely
different on receive and transmit ferrule. The flaring ring on the ferrules provides
the bearing surface for the clamp mechanism integrated in the SMD header. Fixation of the pigtail fiber on the SMD header is done by a snap in mechanic that holds
the ferrule with a certain force within the header cavity after the plug in force has
been exceeded. To remove the fiber, a higher pull-out force is needed.

16.2.4 Device Testing
At the end of the manufacturing steps, an additional final test of the MOST device
is conducted. In contrast to the previously described tests, this test is conducted on
the physical and the logical level. The test aims to verify the reliable function of thedevice and to detect possible errors from the manufacturing process.
By suitably choosing the stimulating signals (radiation power, signal curve form),the system reliability at low input signal levels can be tested. Additionally, thepower of the FOX is tested at the optical outputs for compliance with the requirements of the MOST Specification. Characteristic error patterns are complete failures of FOX or FOR, insufficient transmission level at the TX output, or an earlyrise of transmission errors at low signal levels.

16.3 Summary 279

This procedural method ensures that devices that are delivered to a customer haveno problems with MOST communication.

16.3

SummaryThis chapter deals with the manufacturing and processing of opto-electronic MOST
components. It explains the differences with regard to the processing of conventional electronics components and points to the demands made on the assembling
and testing methods.
Several years of experience with MOST25 in the field have proven that the methods
described no longer pose any practical problems. They are well-established and stable.
With MOST150, the demand for an increased data rate has been answered but may
be not satisfied for all times. The SMD FOT gives an answer on the demand forcomponents that simplify handling with regard to manufacturing. It can be placed
by a machine and soldered within the reflow soldering process potentially eliminating the need for selective wave soldering. Due to its nature of being a true surface
mount component, the area on the opposite side of the PCB is not blocked for otherelectronic components. Thus valuable PCB area is deallocated by using an SMD
header.

280

281

17

Gateways to MOST

Several communication systems are often used and connected via a central gateway
in a car. Signals interact via this gateway.

17.1

Distribution of Signals via a Gateway

Figure 17.1 shows an example of the distribution of signals in a vehicle network.
The ABS sensors generate speed sensor pulses depending on the speed of thewheels. The ECU converts the pulses into the signal WheelSpeed, which is madeavailable to all ECUs connected to this CAN and to the gateway via the Powertrain
CAN. This kind of transmission of information is based on the Publisher Subscriber
Model. The sender (publisher) cyclically sends its data and the receivers (subscribers) read the data from the bus if required. In the example given, the central gateway receives the data and transmits them to the Infotainment CAN. There, the data
are transferred into the MOST system by the HMI, which implements the gateway
functionality. The signal WheelSpeed is used, for example, by the navigation systemfor correcting the navigation data, or for detecting the vehicle position in tunnels
where GPS signals cannot be received (dead reckoning). The radio, too, needs theinformation for adjusting the volume. In the MOST system the signal WheelSpeed
is converted to a property of the FBlock Vehicle.

Body CAN 100 kbit/s

Central Gateway

Infotainment CAN 100 kbit/s
WheelSpeed
Nav

WheelSpeed
ECU
ChassisImpulseABS
Sensors

MOST
25 Mbit/s

Radio

Infotainment

Fig. 17.1: Example of a signal transmission from the ABS sensor into the MOST system

Whereas the Powertrain CAN uses a bit rate of 500 kbit/s, the Infotainment CAN
uses a bit rate of 100 kbit/s. A CAN – MOST Gateway is integrated into the Head
Unit (Human Machine Interface, HMI). As shown in figure 17.1, the signal WheelSpeed must be converted both, in the central Gateway and in the HMI. A bit rate

282 17: Gateways to MOST
adaptation must be performed in both gateways and, additionally, a protocol conversion in the HMI.
Gateway

Stack
System 1

Stack
System 2

Slow Bus

Fast Bus

Fig. 17.2: Basic structure of a Gateway

17.2

Architecture of a Gateway

Figure 17.2 shows the basic architecture of a Gateway. Usually, the complete stack,comprising all seven layers of the OSI communication model (Open Systems Interconnection Reference Model), must be implemented for each bus system. The
Gateway Engine is placed above, routing the signals from one system to the otheron the basis of the static Routing Table. The Gateway Engine lists all signals withsource and target and is generated from the central In-car Network Database of theOEM. The following are the tasks of a Gateway:

Address conversion

Message conversion

Intermediate buffering of the messages

Packet confirmation

Flow control and bit rate adaptations

Routing of the signals

Network management



Error managementLocking/separating of the buses, if required (e.g., flashing/programming of two
buses at the same time)Authentification of message senders/receivers (e.g., only ECU x in MOST may
send to ECU y in the CAN)

17.3 MOST – CAN Gateway 283

The listing shows that the implementation of gateways is usually complex and error-prone. The different bit rates of the networks can result in delays and loss of
messages.
The structures mentioned will now be explained in detail, taking the MOST – CAN
Gateway and the MOST – Bluetooth Gateway as examples.

17.3

MOST – CAN Gateway

The MOST – CAN Gateway is implemented in the HMI or in the central gateway.
Figure 17.3 shows the structure. There are different levels of abstraction for the
CAN bus and the MOST Interface. Whereas there are signals that are transported toa specified position in the CAN frame, the MOST Interface consists of a function
block, i.e., the signals on the MOST side are treated as properties of the function
block. All important signals that have to be exchanged between the MOST systemand the rest of the vehicle network are represented in one FBlock, e.g., Vehicle[FBVehicle 1.6] or, when reflecting also the source domains of the information, in
multiple FBlocks, e.g., Powertrain, BodyCompartment, HumanInterfaceController
and so on.

CAN frames(1)
CAN (2)(3)

MOST interface
HiRes
Wheel
Speed Distance

IgnitionKey

FBlock: VehicleData:
60.00 km/h
Function ID: IgnitionKey
Data:
key present
Function ID: HiResDistance
Data:
10000.1 km
Function ID:
Data:

FBlock: Diagnosis
Function ID: GetData
Data: data
Function ID: PutData
Data:
data
Function ID:
Data:
Function ID:
Data:

FBlock:Function ID:
Data:
Function ID:
Data:Fig. 17.3: Structure of the MOST CAN Gateway [according to Por 2004]

MOST

284 17: Gateways to MOST
In the example given in figure 17.3, the signals WheelSpeed and HiResDistance(high-resolution odometer reading) are copied from the CAN frame 1, and the signal IgnitionKey (status of the ignition lock) from the CAN frame 2 onto the corresponding properties of the FBlock Vehicle. The MOST devices interested in theseproperties can subscribe to these properties by using the notification mechanism at
the FBlock Vehicle in the gateway.
If a diagnostic protocol is used in the gateway, flow control must be implemented
due to the different bit rates.
The opposite direction, where signals are originated on MOST and need to be gatedon CAN, the Gateway is instantiating one or more Shadows. These Shadows are
keeping themselves registered for notification, in order to get posted upon statuschanges on the properties of the related FBlocks.
A Protocol-Gateway therefore is—from the perspective of any other native MOST
element, FBlock or Shadow in the ring—following all MOST stereotypes in a fully
MOST Specification compliant way.

17.4

MOST – Bluetooth Gateway

The Hands Free Profile [HFP 1.5] was defined for connecting a cell phone with aheadset or the telephone unit in a car. The profile comprises the role of the Audio
Gateway (AG), which is usually adopted by the cell phone, and the role of theHands Free Unit (HF), which occupies the headset or the MOST Bluetooth Gateway in the car (fig. 17.4).

BluetoothConnection

Hands-Free
Unit
(HF)

CellularConnection

Cellular
Network

Bluetooth
Audio Gateway(AG)

Fig. 17.4: Roles of the Hands Free Profile [according to HFP 1.5]

In addition to the Control Channel, the audio channel also has to be routed in theBluetooth Gateway.

17.5 Routing of the Control Channel 285

17.5

Routing of the Control Channel

Figure 17.5 shows the stack architecture of the Control Channel in a MOST – Bluetooth Gateway. It becomes clear that Bluetooth and MOST have a similar architecture. While the FBlock Bluetooth is placed on the MOST Stack, Bluetooth uses the
profile Hands Free Control for controlling the Hands Free Unit. It basically standardizes the Call Handling. This comprises taking calls and setting up and terminating the audio channel (see also appendix B 2.5). The Gateway Engine connects theservices of the Bluetooth profile with the properties and functions of the MOST
function block Bluetooth.
Gateway

Application(Audio driver)Hands-Free
control

Hands-Free
control
RFCOMM
LMP

SDP

L2CAP

RFCOMM
LMP

SDP
NetService
Basic Level

NetService
Basic Level

Network Interface
Controller

Network Interface
Controller

MOST
Audio Gateway

MOST
DeviceL2CAP

BasebandBaseband

Radio

Radio

Bluetooth
Audio Gateway

BluetoothHands-Free
Unit

Fig. 17.5: Architecture of the Control Channel

Figure 17.5 shows the simplified structure of a possible audio connection setup in
the case of an incoming call. The audio connection setup is initiated by the HFP(AG). The information about the successful setup is then available in the HFP (HF)
and is passed on to the Gateway Engine. It is only now that the audio setup via
MOST takes place. For that purpose, the Gateway Engine calls the method
BuildSyncConnection of the FBlock ConnectionManager (CM), which then sets up
the synchronous MOST connection between the Bluetooth Gateway and the amplifier by using the methods SourceConnect and Connect. Using BuildSyncConnection.ResultAck, the ConnectionMaster reports the successful setup to the Bluetooth
Gateway. At the same time the ring tone is created in the MOST system.
Entries in the phone book can be exchanged between the cell phone and the MOST
system by means of AT commands or the Synchronization Markup Language(SyncML), if the latter is implemented. Another possibility is the Phone Book Access Profile (PBAP) defined for that purpose, which then has to be implemented in
the cell phone and in the gateway [PBAP].

286 17: Gateways to MOST
HFP
(AG)

HFP
(HF)
Established Service
Level Connection

Incoming
Call+CIEV: (callsetup = 1)
BuildSyncConnection
Audio Connection
set upSourceConnect
Connect of sink
BuildSyncConnection.ResultAck

Audio Connection

Audio Connection

Fig. 17.6: Basic sequence for the setup of a synchronous connection

In cars, the SIM Access Profile (SAP) is also of interest [SAP]. It is used exclusively for exchanging the SIM data between the cell phone and the car. By means of
the SIM Access Profile, the telephone integrated in the car can read out the SIM
data from the cell phone and use them as long as it is registered via Bluetooth. This
makes a second SIM card unnecessary.

17.5.1 Routing of the Synchronous Audio connections
In addition to the Control Channel, the synchronous audio connection also has to berouted. In this context, the frequency spectrum and, if necessary, the amplitudes
have to be adapted. The Bluetooth SCO channel is adapted to the audio quality ofan ISDN channel, i.e., it has a sample rate of 8 kHz, which allows a signal spectrumof up to 4 kHz.
Bluetooth uses the Pulse Code Modulation (PCM) or the Continuous Variable Slope
Delta Modulation (CVSD) for source coding of the audio signals on the SCO channel.
The PCM format can be used with a logarithmic A-characteristic (A-law) or a logarithmic µ-characteristic (µ-law). As the sampling values are quantized with 8 bits
and the sample rate is 8 kHz, a bandwidth of 64 kbit/s is required on the SCO channel.
The CVSD modulation transmits the differences between the anticipated and the actual sampling value. It is a type of delta modulation, in which the sampling periodof the approximated signal is incremented or decremented progressively, in order toimprove adaptation of the signal to the analog input signal. For the conversion, only
the positive or negative changes compared to the preliminary value are indicated bya bit. The sample rate is 64 kHz and the amplitude is 16 bits. As only one bit istransmitted at a time, the channel also requires 64 kbit/s.

17.5 Routing of the Control Channel 287

Usually PCM modulation is used for Bluetooth. The adaptation of the different
sample rates is effected by using a bi-directional asynchronous sample rate converter, as is shown in figure 17.7. In the case of audio data transmitted from theBluetooth channel into the MOST system, the converter increments the sample rate
to 44.1 kHz by means of interpolation. In the opposite direction, it decrements the
sample rate to 8 kHz. A low pass filter is integrated into the converter.

PCM
16 Bits 8 kHz
PCM
Codec
Cell phone

8 kHz

Bluetooth

Asynchronous
samplerate converter

GatewayPCM
44.1kHz

INIC

MOST

Amplifier

8 kHz 44.1kHz

Fig. 17.7: Architecture of the Audio Gateway

The controls of the Streaming Channel and the Control Channel must be coordinated by the gateway. A valid signal must first be applied to the synchronous connection, for example, before the amplifier switches to the telephone source. Otherwise whistling or other noises might occur.

288

289

18

MOST Applications

This chapter deals with an overview of some MOST based applications, startingwith a glance on the history of infotainment systems and an outlook into the futurefrom today’s perspective.

18.1

Overview

Back in the mid 90’s, the automotive entertainment market was confronted withnew technical and operational requirements:
1. The growing number of entertainment components supplying and consuming all
kinds of information in the car increased the complexity of interconnecting andcontrolling such components.
2. The car makers struggled with Electro Magnetic Interference (EMI), as well as
the weight and cost of the wiring harnesses, caused by the multiple different
hardware platforms. The diagnosis of the different components could not be inherently handled by the system, but only through each individual component.
3. The final user (driver or passengers) had and still has the need to operate all thecomponents through different, individual human machine interfaces.

To build a system, each component (whether a sink or a source of information) has
to have the capability and possibility to communicate with other components insuch a way that the information can be used in real time (minimum latency). Furthermore, the information sometimes is enhanced and post-processed (synchronous
co-processing), and re-used again as a new set of information. The infotainment
Head Unit, sometimes also named ‘system controller’ should govern all events inall components in such a way that the user is no longer confronted by the complexity of the system, but has to deal with the results produced by the system only!
This set of requirements lead to the design of the MOST system, enabling the transport and ’broadcasting’ the information (data) and the control commands in such away, that media-signals could also be transported in real time.
MOST quickly became the backbone of all modern infotainment systems and is
now the de facto standard for infotainment networking in the automotive industry.
However, MOST does not only stand for the transport of the data. Equally important is the fact that MOST offers a standardized set of APIs enabling the design of290 18: MOST Applications
an appropriate software structure around the logical representation of all components (proxies) in the system controller.
And last but not least, MOST was and still is the enabler to overcome the real challenge in infotainment system design: Provide the flexibility and the scalability tocover different market requirements with different levels of functionality and performance based on a unique but still stable system architecture.
The FIRST Generation of MOST based Infotainment Systems in the market canbe characterized by a strongly distributed architecture, driven by a large variety of
infotainment functions and features with limited and at the same time expensive
computing horsepower. The result was a pretty strongly modularized approach withmany dedicated system components carrying dedicated functions. The system components were designed and manufactured by several suppliers, represented by theirindividual, sometimes diverse skill sets in hardware and software design and manufacturing. Hence, the difference in quality and performance of the components washigh, until a later stage when everybody had caught up in the learning curve. Figure18.1 shows such a system.

Fig. 18.1: 1st Generation MOST based Infotainment Systems

The SECOND Generation of Infotainment Systems is characterized by a higher
physical integration of the external components into the headunit. The number ofcomponents could be typically reduced from 12-15 to 6-8. Cost, weight and power
consumption were typically down by up to 30%, compared with 1st generation systems of similar functionality and performance. Examples for such physical integration are ‘Tuner-Amplifier’ modules or the integration of navigation computing
modules into the headunit (see fig. 18.2). The field results of the 1st generation
MOST cars (BMW’s 7 Series E65 or Daimlers E-Class W211) vs. the 2nd generation cars (BMWs 5 Series E60, MB C-Class W203) are the proof of this.

18.1 Overview 291

Fig. 18.2: 2nd Generation MOST based Infotainment Systems

The THIRD Generation of Infotainment Systems are the basis for the systems
established on the market from 2005 onwards. They are characterized by the replacement of hardware components through software modules (see fig. 18.3). Further cost, weight and power consumption reduction are achieved (-30%). Many system functions are absorbed by the Head Unit and a lower number of external systemcomponents. In some cases, the entry level infotainment system does not even contain any external system components anymore, while through the built-in MOST interface still offering the possibility to attach advanced options such as externalsound amplifiers, media changers or country specific tuner options like satellite radios.. Here, devices identical to those in the mid and high-end system can be used.

Fig. 18.3: 3rd Gen Mid Level Infotainment System

292 18: MOST Applications
The FOURTH Generation of Infotainment Systems will be seen in the Market
from 2013 onwards. With the functions and features of MOST150 and particularly
its enhanced bandwidth, it will finally be possible to transport all infotainment related video data over the MOST network. The video content is transported in acompressed way, as all media data is provided in a compressed format anyway(over the air through digital broadcast or wireless LAN, on DVD or Blu-ray discs orin the memory of portable media).

Typical systems will comprise an infotainment headunit and some external components like sound amplifier, digital tuner (country/region specific), media interface,and rear seat entertainment units or the inststrument panel cluster (IPC), which intimes of LCD panels, are gaining more and more video capabilities. Optionally, aback-up camera, which as of today is still connected to the headunit via separate
video cable, may be integrated into the MOST system (see fig. 18.4).

Fig. 18.4: 4th Generation MOST based Infotainment System

The following three sections will elaborate on three examples of MOST systemcomponents: infotainment headunit, media interface and sound systems.

18.2 Infotainment Headunit 293

18.2

Infotainment Headunit

In 2010’s systems, a typical infotainment headunit is a scaleable computing platform optimized for the harsh automotive environment with computing power reaching from 32-bit based 400 MIPS up to 2 GIPS dual processor architectures. In addition, dedicated hardware (DSPs) for Audio/Tuner and graphic processing is used.
State-of-the-art 32-bit operating systems are applied like Microsoft
WinCE4Automotive, QNX, embedded Linux or Micro-Itron.
Accordingly, a respective software suite is required to be matched to the scalabilityof the hardware. Innovations concerning minimum start up time, real-time processing, processing streaming data, server capability of the modules, multiple graphic
drivers for multi-user applications and multimodal HMI operation are realized
through advanced application software modules, advanced frameworks and realtime operating system (RTOS). It is extremely useful to implement pervasive software architecture from entry level up to high-end systems, following the MOST
philosophy.
In order to guarantee fast startup of the individual system components, which isvery important for providing the functionality of all system components to the user
quickly, very often an additional 16-bit microcontroller, often called I/O processor,
with a different, lean OS is used. This device also typically implements the gateway
functionality (MOST-CAN), in case the headunit carries the gateway.

Fig. 18.5: Infotainment Headunit based on FPGA architecture294 18: MOST Applications
As MOST defines a comprehensive set of data types to exchange information ‘signal based’ and includes an expandable and customizable set of already definedAPIs, a very interesting approach consists of a unified communication architecture
for a): the communication over the physical MOST network, b): the communication
between the main CPU and the I/O processor and c) the ‘on chip’ communication
inside the 32-bit engine. The majority of the MOST based headunits from the 1st
and 2nd generation MOST systems have been using such SW architecture, howeverat the time being pretty much proprietary solutions.
Today, SW frameworks offering ready-made solutions for such software architectures are widely used and commercially available, e.g., from K2L (www.K2L.de)Market leaders in field-programmable gate arrays (FPGA) have committed theirnext generation devices to support scaling the main board and interfacing hardware
in a very flexible and optimized way. The advantage of such a concept is a scalable
approach providing a number of hardware levels, which can be re-configured by the
FPGA code through the system software (see fig. 18.5).
A different approach is shown in figure 18.6. It is the even stronger re-use of PClike architectures. In this case, the FPGA is replaced by a dedicated south bridge
chip (I/O Hub), similar to what can be found in PCs. However the south bridge
chips used in PCs cannot be used due to missing Audio/Video ports. Here, the still
significant difference between car applications (embedded multimedia units) andPC applications becomes obvious, forcing the development of automotive specific
I/O hubs.

Fig. 18.6: Infotainment Headunit based on PC architecture18.3 Media Interface Devices 295

It has to be seen if and until when the complete integration of the multimedia (A/V
Processing) functionality into the main processor will be realized. In any case, suchan integration will require the existence of a comprehensive set of software suites
starting from RTOS and framework, offering different packages of well debugged
software suites, incl. applications as network subsystems (MOST), graphic libraries
and drivers, navigation, voice control and voice enhancement, multi standard media
decoders, discrete and enhanced sound processing, digital radio processing, genericsystem diagnosis, system start-up and shutdown including the network control, etc.
As of 2010, different initiatives exist to create such an ecosystem. However, themigration is quite challenging from a performance, scalability and design/software
integration perspective, particularly given the constantly and rapidly growing feature set of mobile/portable devices such as smartphones and media players, which
are driven by the much higher volume consumer industry.
Another trend which may become even more relevant for the design of future Infotainment headunits is the emerging requirement for driver assist functions and features. As the infotainment system provides the main user interface, it is obvious that
there will be some overlap between the classical infotainment domain and the upcoming driver assist cluster, which will also affect the infotainment headunit design
and architecture.
Given the fact that both non safety related as well as safety related functions need tobe considered, a more modular approach may be even better, allowing the development of different parts of the headunit according to different Automotive Safety
Integrity Levels (ASIL) according to the ISO 26262 standard.
In any case it is obvious that a powerful communication backbone providing different levels of communication methods, as MOST provides it, becomes even more
important than before.

18.3

Media Interface Devices

The variety in media devices is constantly expanding and the design of the devices
is rapidly changing. MP3 players (the most prominent one being the iPod) using
different APIs and sometimes also copy protection/content management methods
require more or less frequent changes on the vehicle side. Some companies even require dedicated hardware (ICs) to authenticate and enable the communication with
their respective products.
Implementing such changes in the multimedia headunit implies a relatively large
development and in particular test and requalification efforts. Other media devices
may not even be available during the time the headunit and the multimedia system
is developed, or may even emerge only during the production time of the car. From

296 18: MOST Applications
a car makers perspective, this discrepancy of the vehicle lifecycle and the consumer
products has become an ever increasing nightmare.
For obvious reasons, it does make a lot of sense to de-couple the rapidly changing
consumer world from the more stable car environment. This is often achieved
through so-called ‘media interface devices’ or sometimes called ‘universal communication interfaces’. Such devices may contain different types of card readers, multiple USB interfaces, and, respective authentication devices, to communicate withspecific, proprietary equipment. Figure 18.7 shows the block diagram of a media interface device.
As discussed in the previous section, today’s smartphones carry more and morefunctions and features: navigation, voice control and, multi standard media servers
and wireless communication including GSM/UMTS and also WLAN. The demand
to attach such devices to the car and use the built-in features is constantly rising.
Using a MOST based media interface device, the car maker has also the flexibility
to react on fast market changes coming from the consumer industry on the one side
while still being able to keep the well defined, carefully architected and debugged
infotainment infrastructure.

Fig. 18.7: MOST based
Media Interface Device

18.4

Sound Systems

Quite often manufacturers offer several optional equipments for each vehicle type.
Different trim levels, reaching from basic systems up to (often branded) premiumsound systems, are available. It is obvious that, although offering different featuresand in particular output power and signal processing capabilities, it is extremely
important that all these trim levels can be controlled in a consistent way from the
network side. A unified control API as provided by MOST is the key to a clean andstraightforward system architecture and integration process.

18.4 Sound Systems 297

Speed-dependent volume control is one example, where the sound system needs tobe networked to the rest of the vehicle. It compensates for disturbing vehicle noisesthat swell with increasing driving speed.
Another example is the generation of acoustic warning signals (chimes), e.g., forpark distance control or seat belt warnings. With growing feature sets of driver assist applications, where the driver is more and more overloaded with visual information, it can be expected that the acoustic information channel to the driver will
get more important. Such signals are transmitted to the Head Unit via the MOST or
CAN bus system, where the real-time behavior is extremely important.
Premium System

In a premium system a multitude of signals is transmitted from the Head Unit orother sources via MOST to a separate DSP (Digital Signal Processor) amplifier,which contains multiple amplifier outputs. This amplifier is also referred to as digital sound processor (see fig. 18.8).
AF Source

DAB
DVB
Phone
TV
DVD
CD Changer
Internet

MOST

D
Diagnostics

Controller
DSP

D/A

V
AmplifierFig. 18.8: Block diagram of a DSP Sound Amplifier

The DSP used does not only allow for a broadband, speed-dependent volume level
increase, but also influences the spectral reproduction characteristics by counteracting the masking influence of low-range noises by a low-frequency level rise at thewanted signal. Noise in a vehicle is mostly very low-frequent and decreases by approximate 20 dB per frequency decade. Thus, a simple broadband level rise of thewanted signal – as in the case of the premium system – leads to a high-range impression, because only low frequencies of the wanted signal are masked by thenoise and are thus less audible. Due to the fact that noise depends on the speed, it
can be estimated via the rev counter or be measured directly by a microphone. This
results in a high-grade closed-loop control system. Typically, the microphone signal(one or multiple microphones may be applied) is also transmitted via the MOSTbus.

298 18: MOST Applications
18.5

Audio and Video Transmission Formats

18.5.1 Audio Streaming
A multimedia system in a vehicle must be able to read the different storage media
and their coding formats. In addition, the different transmission formats of digitalaudio broadcasting and digital video broadcasting must be identified. Depending on
the equipment variant, high transmission rates may be generated, which must beprocessed by the MOST system.
In contrast to the vast majority of other bus systems coming from different application areas, MOST has been designed for Multimedia Data Transport throughout asystem, as its name already indicates.
In contrast to home systems, the car requires a multi source / multi sink environment, where multiple audio and video sinks, amplifiers, headphones and multiple
displays are operated at the same time.
There is a great variety of transmission formats in the audio field. In addition to stereo reproduction, different surround formats are relevant for the use in vehicles andare often employed in professional systems. The following is a rough overview:
StereoThe uncompressed signal has a data rate of 1.4 Mbit/s at a sampling rate of 44.1
kHz and a 16-bit resolution. The most widely used compression rate is 128 kBit/s
for MP3.
Analog Dolby Surround Pro Logic

This system consists of the channels front right, front center (center speaker forvoices), front left, and rear left, rear right as one channel. The surround channel isapplied to the two rear speakers and is time-delayed with regard to the front channels and band-limited to 100 to 7,000 Hz. The center speaker positions the voices tothe center, which, in a car, makes localization rather independent of the listening
position.
Analog Dolby Surround Pro Logic II

The Dolby Surround Pro Logic II enhances the Pro Logic to a 5.1 system by incorporating two separate surround channels without band limitation, and a subwoofer
channel.

18.5 Audio and Video Transmission Formats 299
Dolby Digital, AC3AC3 comprises five separate channels without band limitation and a separate subwoofer channel (Low Frequency Effect, LFE) limited to 120 Hz. At a sampling frequency of 48 kHz and a 16-bit resolution, transmission rates of 384 to 448 kbit/s
accrue for the data which have a lossy compression ratio of 10:1. For two-channel
stereo, the data rate is reduced to 192 kBit/s. Whereas MPEG-2 is the DVD standard in the video field, AC3 is the DVD standard in the audio field. MPEG-2 canonly be used on a DVD as an additional audio coding format.
MPEG-2MPEG-2 is a coding standard which can also be found on a DVD for audio signals,
in addition to AC3. The data rate for six channels is about 400 kbit/s. MPEG-2
AAC (Advanced Audio Coding) is an enhancement which manages with half thedata rate for the same quality as MPEG-2 and admits the coding of up to 48 audio
channels, 16 subwoofer channels and 16 commentary channel. MPEG-2 is used as astandard in digital TV d(DVD satellite, DVD cable, DVD terrestrial). In Japan,
MPEG-2 has been used as the exclusive sound format for all digital broadcasting
systems since the beginning of the year 2000.
Digital Theatre System (DTS)DTS is also a 5.1 system. Compared to AC3 it is distinguished by a better soundquality and increased dynamics. DTS has considerably less data compression andworks with 1.536 Mbit/s for surround coding.
Logic 7

The 7.1 surround system developed by Lexicon controls the eight independent
channels either digitally or develops a corresponding control from a stereo signal on
the basis of a matrix decoding. It is thus possible to simulate the surround impression and achieve a very good ambient sound reproduction. A 5.1 source signal isenhanced to 7.1. Logic 7 is often used as professional system in vehicles.

18.5.2 Video Streaming
In the video field, a variety of different formats is applied, driven by different companies and different markets. Figure 18.9 gives an overview of the common
graphic/video standards.

300 18: MOST Applications

Fig. 18.9: Overview of common graphic/video standards

Rotating media like video CD, DVD, BD, digital video streams from DVB or DMB
tuners, or any kind of portable device will contain compressed video.
Usually, consumer video applications depend on digital data in a compressed format. The reason is clear: it is the cost for either the data transport channel (over the
air or the Internet) or the storage capacity (disk space, memory).
For pre-recorded content, there is no need to transport uncompressed video. For
compressed video transport, two different principle scenarios are possible. Eachscenario has advantages and disadvantages, and these must be weighted under the
specific project requirements, including aspects of multi-seat capabilities, function
related costs, global costs, flexibility, expandability, bandwidth and other hardware
requirements.
Scenario 1: Transcoding at the source

Stream navigation and decoding is done directly at the source. Video and audio are
put onto MOST separately from each other. Video is transcoded or re-encoded into
a common, to be defined MOST format, e.g., H.264 or MPEG2/4. Audio istranscoded to PCM. Due to the separation of audio and video, the video sink and theaudio sink can be independent from each other (example: video is sent to one ormore displays, audio is sent to the amplifier). The system uses a push mode fromthe source towards the sinks. The synchronous nature of MOST with its determined,
minimum and constant delay supports the separate transmission of the Audio andVideo stream in an optimum way.
Also for DVD (and potentially DivX also) the handling of subpicture informationmust be considered. It can either be imprinted on the transcoded frame or sent separately (with the video) to the sinks.

18.6 MOST for Driver Assist Applications 301
Scenario 2: Transfer of program stream and decoding at the video sink

The data is transferred in the original format (Audio + Video, Transport stream orprogram stream) as provided by the source over MOST to the sink, e.g., a display
unit. Decoding and navigation/control are done in the sink.
Audio can be routed back onto MOST towards a detached audio sink (Main Amplifier, detached headphone amplifier). The system may either use a pull mode to request data packets from the source, in case the source is a memory based medium(HDD, Media Drive, …) or a push mode, e.g. for sources like digital tuners. The
video sink may then use a push mode to transmit decoded audio and video data to
additional sinks which are in copy mode (i.e., viewing/listening to the same content).

18.6

MOST for Driver Assist Applications

Driver assistance systems are about to conquer the market. The latest studies forecast an annual market growth from 9 to 62 million units between 2005 and 2013. In
current and future vehicles, driver assistance functions are starting to complete andextend the feature set of traditional infotainment systems. Along with information
features such as navigation systems, traffic information, and function warnings, thenumber of vehicles with driver assistance features like camera systems, distancecontrols, or lane departure warnings will be rapidly increasing. In this application
domain, communication faults become a serious issue since they can lead to severely damage objects or even injure persons. Necessary improvements are being
investigated, and recent studies show that MOST might be able to support safetycritical applications as well.

Fig. 18.10: Evolution of Electric/Electronic
Domains in the vehicle

Driver assistance systems are on the way to become an integral part of the car, withinterfaces to many different clusters of automotive Electric/Electronic systems.

302 18: MOST Applications
Taking into account the complexity of the applications and the different areas of the
car that have to exchange information, it will become obvious that an appropriate
network infrastructure is of crucial importance for the efficiency of the system. So
in addition to the five classical domains of an electric/electronic network architecture in the car, a new one dedicated to Driver Assist Systems is being introduced(see fig. 18.10).
The existing incarnation of MOST, having been developed and optimized for infotainment, can probably only be used ‘as is’ for very limited use cases of driver assist applications. On behalf of the MOST Cooperation, investigations are being
made on which measures have to be taken in order to fulfill the requirements of theforthcoming safety standard for the automotive industry ISO 26262, which also respects necessary requirements of current standards, e.g., IEC 61508.
With respect to the physical layer, the ring architecture alone has too many limitations for driver assist applications. Therefore, alternative topology options like staror daisy chain are being developed. On the wiring side, fiber optics may not be suitable for all use cases, while at the same time the well established UTP physicallayer for MOST50 may either limited in bandwidth expansion or not robust enoughfor upcoming EMC requirements from hybrid or electric cars. Consequently, theMOST standard is being completed by cost effective, robust alternatives, e.g., Coax
cable based physical layers.
As a solution on the protocol side, an architecture with a safety layer as the basis forsafety related applications has been proposed. A safety layer provides safe communication over a MOST network using safety codes and a dependable service for thetransmission of safety related application data over a MOST network.
Looking into the future, one possible incarnation of the 5th generation MOST systems could be the use in both the infotainment and the driver assist area, supported
by different topologies and different physical layers.

303

Appendix

304

305

A

The Description Language Message
Sequence Chart (MSC)

The automotive area mostly uses MSCs for describing the dynamic behavior of distributed telematics and infotainment systems. The syntax and the semantics of the
Message Sequence Charts were standardized in the ITU-T Z.120 [ITUZ120] and in
the Corrigendum 1 by the International Telecommunications Union, ITU. A large
number of graphic notations for describing the interaction of components were suggested in the past. The Message Sequence Charts proved an intuitive form of describing the asynchronous exchange of messages between the instances of a communication system.
The semi-formal notation originates from the telecommunication area, particularly
the areas Requirements Engineering, specification, and the design of telecommunication distribution systems. MSCs were then always considered as one aspect of an
SDL (Specification Description Language) model. Meanwhile, however, MSC has
detached itself from SDL and the standardization has been pushed on by the ITU.
MSC aims at creating a technical language for specifying and describing the communication behavior of system components among each other and with their environment by means of exchanging messages. As the communication behavior in
MSCs is described in an intuitive and transparent manner, the MSC language iseasy to learn, use and interpret. In combination with other languages, it supports
methods for system specification, system design, simulation, test and documentation.
MSC is independent of the used communication protocol. In addition to the bus
communication, the communication models can be specified between the software
components within a device, if they are relevant for the system behavior.
The MSC standard supports a modular structure. Recurring communication procedures only have to be described once and can then be used as often as desired as
reference. There is no obligatory completeness (in contrast to statecharts) and it ispossible to itemize, depending on requirements. Difficult and unclear items are
specified in more detail.
However, when describing MOST sequences, a necessary extension for complex
data types became obvious. For that reason the so-called Named Parameters wereintroduced, which are described in the MOST MSC Cookbook Specification, chapter 5, appendix A: Extension to MSC2000 (Named Parameters).

306 A: The Description Language Message Sequence Chart (MSC)
MSC defines the two categories: Basic MSCs and HMSCs (High Level MSCs).
Figure A.1 illustrates an example of a Basic MSC, referred to as TuneNextFmStation. It describes the sequence of changing from a currently selected FM radio station (BBC) to the FM station (RadioTokyo) stored next in the list. The Basic MSC
abstracts the sequence and only shows the exchange of information between themain components AmFmTuner_Controller and AmFmTuner. At the start, the system is in its initial state – radio station BBC is selected. The HMI sends the message
USERDEF_HMI_Event with the parameter User selects new Station in ListFM to
the AmFmTuner_Controller. The latter sends the message ListFM.Set with the respective parameters to the AmFmTuner, which executes the action. If the new radio
station (RadioTokyo) is tuned, the AmFmTuner sends the new list status(ListFM.Status) and the station name (StationInfo.Status) received via RDS to the
AmFmTuner_Controller.
msc TuneNextFmStation

page 1 of 1
HU

ANT

AmFmTuner_Controller

AmFmTuner

Initial StateUSERDEF_HMI_Event(User='User selects new station from
ListFM')

Current selected Fm radio station"BBC"
ListFM.Set(Data={Selection[0]='aktiv'})
if (new sender is selected)
Current Fm radio station"RadioTokyo"
ListFM.Status(Data={Selection[0]='aktiv'})
StationInfo.Status(Data={SenderName='RadioTokyo',
SenderNameInfo='via RDS received
name (orginal)'})Fig. A.1: Example of a Basic MSC

Instances

Instances are, apart from the messages, the most important language constructs of
Basic MSCs. Instances are components which exchange messages among eachother or with the system environment. CAN nodes, MOST FBlocks etc. are examples of instances. Instances are illustrated as instance head attached to a verticalline. The instance head contains the instance name. Admissible instance names in
the MOST domain are, for example, NetBlock, AmFmTuner and PowerMaster.
Additionally, the type of instance can be indicated above the instance head (cf. fig.
A.1). The end of the instance is described by an instance end symbol (▬). That

A: The Description Language Message Sequence Chart (MSC) 307

does not necessarily mean that the instance is completed here. It only means thatwithin this MSC no further events are described for this instance.
MOST uses MOST Instances, as they are called, General Instances and UserDefined Instances. MOST Instances have a function block name (FBlockID) and an
optional instance ID (InstID). The General Instances can be defined freely and areused for instances which cannot be illustrated by a MOST function block.
A user-defined instance is the user interface of a MOST instance, such as the Human Machine Interface (HMI). An abstraction layer separates the user activities in
the head unit from the user-defined instance. It translates, for example, the actuationof a pushbutton or switch into events which the user-defined instance can trigger or
receive. When the system is modeled, only one single event is thus necessary for
the HMI instance for selecting the next radio station stored in the list
(TuneNextFmStation, cf. fig. A.1), irrespective of the complexity of the menu navigation.
Messages

MOST Messages in MSCs should always correspond to the MOST function catalog. Messages are illustrated by arrows indicating the time lapse. The arrow end describes the sending and the arrow tip the processing of a message. The labeling consists of the message name and optional parameters which are indicated in brackets
underneath the arrow. Messages are arranged along the instance axis according totheir chronological appearance. Since the order of sequence is firmly defined, thisarrangement is also referred to as total order.
Prefixes were introduced to facilitate the differentiation between MOST, CAN and
HMI messages. Messages sent by an HMI Instance get the prefix HMI_Event andmessages received by the HMI Instance get the prefix HMI_Update.
The messages Processing or ProcessingAck can occur in a MOST system if amethod was triggered by means of the OPType StartResult or StartResultAck. If thecalled instance cannot answer within the predetermined period of time, it sends themessage Processing, in order to inform the sender that its query is still being processed. Processing messages can occur at any time in any part of an MSC, after the
method has been queried. For that reason it does not always make sense to integratethese messages into the MSC, as this makes reading the MSCs difficult.
Environment

The diagram area of an MSC is confined by a rectangular frame, referred to as Environment. It defines the system environment of the MSC. The messages comingfrom the system environment or being sent there, start and end on the environment(cf. the message USERDEF_HMI_Event in fig. A.1). In contrast to the total orderalong the instance axes, there is no order defined for events on the Environment.

308 A: The Description Language Message Sequence Chart (MSC)
Actions

In addition to the messages, actions can be specified by instances. An action in an
MSC is presented by a rectangular symbol, which can contain any text (cf. fig. A.1– “currently selected fm station BBC”).
Timer

MSC offers the language constructs Timer-Start, Timeout and Timer-Stop for labeling Timers. Timer-Start defines the starting, Timeout the lapse and Timer-Stop thereset of a Timer. A Timer is always assigned to an instance. For that reason thegraphical Timer symbol (cf. fig. A.2) is always connected to the corresponding instance. A Timer symbol includes the name of the Timer and optional Timer parameters. An hourglass symbolizes the Timer-Start, an arrow starting at the hourglass symbolizes the Timeout, and a cross symbolizes the Timer-Stop.
msc Timer

page 1 of 1

FBlock1

Timer
[10]

FBlock2

Timer

FBlock3

Timer

Fig. A.2: MSC Timer symbols

Condition

A condition relates to a number of instances of an MSC. Conditions are graphically
represented by hexagons covering the instances they are relating to. In MSCs, conditions are used for describing important system states (e.g., initial state in fig. A.1).
Apart from the Basic MSCs, there are structural language constructs, as they arecalled, which exceed the description of the message sequence. By means of theselanguage elements, MSCs and parts of MSCs can be combined to complex sequences (Inline-Expression and High-Level MSC), MSC diagrams can be reused inother MSC diagrams (References), MSC instances can be refined (Decomposition),and general event structures for instances can be defined (Coregion and GeneralOrdering). However, this clause will only describe High-Level MSC (HMSC). A
detailed description of the other language constructs is given in the MSC Specifications ([Z.120 99], [Z.120AB 98], [Z.120C1 01]) and the MOST MSC Cookbook[MSC].

A: The Description Language Message Sequence Chart (MSC) 309
High-Level MSC

Whereas the Basic MSCs describe the communication between different participants on the message level, the High-Level MSCs (HMSC) offer a graphical way of
combining individual MSCs with each other (see fig. A.3).
msc Overview

g_eMarket

JAPAN

USA

Fig. A.3: Example of a High-Level MSC [MSC]An HMSC abstracts instances and the message sequence. It is designed for presenting the combination of MSCs. Diagrams of this kind are thus often referred to as
Roadmaps. By means of the HMSCs, it is possible to present parallel, sequential
and alternative combinations of MSCs in a simple manner. The HMSC illustrated infigure A.3 describes the sequence determining the features of a MOST infotainment
system depending on the sales market, i.e., the global enum-constant g_eMarket,
JAPAN or USA.
This chapter could only deal with the most important elements of the MSC language. Apart from the mentioned constructs, further concepts are specified, making
MSC a complete specification language. More information and a complete description of the MSC language, as well as MOST-specific adaptations can be gatheredfrom the SDL forum (http://www.sdl-forum.org) and the MOST Cooperation server(http://www.mostcooperation.com) in [MSC].

310

B

Data rate of the Packet Data
Channel of MOST25

The net data rate of the Packet Data Channel of MOST25 basically depends on the
bandwidth of the channel and the length of the telegram. The number of telegram
segments is calculated according to the following equation [DS 8104]:

 Pd  Ph 
Tp  roundup Af 
 Pd  Ph 
 roundup (15  SBC ) * 4 (Equation B.1)

 Pd  10 
 roundup Frames (15  SBC ) * 4 
The transmission time of a telegram depends on the sample rate (number of frames
per second) and a delay time, which is required by the MOST Network Interface
Controller for providing the next telegram:Tt 

Tp  Tas
Fs(Equation B.2)

The net data rate is calculated with Tt and Pd according to the equation:R

Pd * 8Bit / sTt

(Equation B.3)

with:
Tp:

Number of telegram segments

Pd:

Number of data bytes in a telegram

Ph:

Number of control bytes in a telegram

Arbitration

1 ByteTarget address

2 Bytes

Data area length

1 ByteB: Data rate of the Packet Data Channel of MOST25 311

Source address

2 BytesCRC

4 BytesTotal

10 Bytes

Af:

Bandwidth of the Packet Data Channel

Tf:Transmission time of a telegram

Ta:

Interval between two telegrams of a node; indicated in number ofthe frames (always 4 frames in the case of the NIC)

SBC:

Value of the synchronous bandwidth control register (between 6
and 15)Fs:

Sample rate (typically 44.1 kHz)R:
Net data rate
Table B.1 summarizes the net data rates for typical telegram lengths and possible
bandwidths of the packet data:

SBC

6
7
8
9
10
11
12
13
14
15

Pd

Unit

1014

512

256

128

64

48

10.841
9.937
8.725
7.611
6.388
5.261
3.975
2.710
1.376
0

9.507
8.602
7.854
6.947
5.827
4.882
3.763
2.580
1.338
0

7.526
6.947
6.451
5.645
5.018
4.301
3.345
2.377
1.272
0

5.645
5.018
5.018
4.516
4.105
3.474
2.822
2.053
1.158
0

3.226
3.226
3.226
2.822
2.822
2.509
2.053
1.613
0.982
0

2.822
2.822
2.419
2.419
2.419
2.117
1.882
1.411
0.891
0

Mbits/sMbits/sMbits/sMbits/sMbits/sMbits/sMbits/sMbits/sMbits/sMbits/s

Table B.1: Net bit rate of the packet data with Ta=4 and Fs=44.1 kHz

Note: For the data rate of the Packet Data Channel of MOST50 and MOST150, seesections 5.1 and 5.6.

312

C
8B10B
A/V
A2DP
AAC
ABY
ACL
ADS
AG
AH
AM
AMA
AMS
ANT
API
APWD
ASYNC
AV/C
AVDTP
BAP
BOSS
BPF
PACK
CACK
CAI
CAL
CAN
CAPL
CDEF
CI
CM
CMD
CMS
CP
CSMA

Abbreviations
8B/10B Code
Audio/Video
Advanced Audio Distribution Profile - a Bluetooth profile
Advanced Audio Coding
All-Bypass
Asynchronous Connection-Less - an asynchronous Bluetoothlink
Asynchronous Data Service
Audio Gateway - Bluetooth
Address Handler
Amplitude Modulation
Active Member Address
Application Message Service
Antenna Tuner
Application Programming Interface
Average Pulse Width Distortion
Parallel Asynchronous Mode of the SP; pin of the NIC
Audio-Video Compatibility Specifications
Audio/Video Distribution Transport Protocol - a Bluetooth profile
Operation and Display Protocol (German: Bedien- undAnzeigeprotokoll)
Bus-Owner/Supervisor/Selector
Bits-per-Frame
preemptive acknowledge
complete acknowledge
Cavity-as-Interface
CAN Application Layer
Controller Area Network
Communication Access Programming Language; programming
language similar to C by Vector Informatik
CAN Data Exchange Format
Configuration Interface
ConnectionMaster (also: Connection Manager)
Command Interpreter
Control Message Service
Control Port of the NIC
Carrier Sense Multiple AccessC: Abbreviations 313

CSMA/CA
CSMA/CD
CSR
CU
DAP
DDJ
DHWG
DoC
DSD
DSP
DSP
DTC
DTD
DTS
ECL
EHC
EHCI-State
EMC
EMI
EOC
EOP
ePhy
ET
FBlockFBlockID
FCS
FHSS
FIFO
FktID
FM
FOR
FOT
FOX
FPGA
FS
FSY
FTDMA
FWHM
GAVDP
GMI
GOEP
GSM

Carrier Sense Multiple Access/Collision Avoidance
Carrier Sense Multiple Access/Collision Detection
Control and Status Register
Critical Unlock
Diagnostic Adaptation Protocol
Data-Dependent Jitter
Digital Home Working Group
Declaration of ComplianceDirect Stream Digital
Digital Signal Processor
Digital Sound Processor
Diagnostic Trouble CodeDocument Type Definition
Digital Theatre System
Electrical Control Line
External Host Controller
External Host Controller Interface State MachineElectromagnetic Compatibility
Electromagnetic InterferenceElectrical/Optical Converter
End of Production
electrical Physical Layer
FBlock EnhancedTestability
Function Block
Function Block Identifier
Frame Check Sequence
Frequency Hopping Spread Spectrum (Bluetooth)First-In First-Out Buffer
Function Identfier
Frequency Modulation
Fiber Optic Receiver
Fiber Optic Transceiver
Fiber Optic Transmitter
Field-programmable Gate Array
Frame Synchronization; sample rate
Synchronization Pin of the INIC
Flexible Time Division Multiple AccessFull-Width at Half-Maximum
Generic Audio/Video Distribution Profile - a Bluetooth profile
Golden MOST Implementations
Generic Object Exchange Profile - a Bluetooth profile
Global System for Mobile Communications - a Bluetooth profile314 C: Abbreviations
GW
HAVi
HCI
HF
HMI
HU
IEEE
IFG
INIC
InstID
IP
ISM
ITU
JPEG
JTAG
L2CAP
LAN
LED
LEG
LFE
LLC
LLD
LMP
MAC
MAMAC
MBM
MCA
MCPL
mCRA
MCS
MCSB
MCTG
MCTH
MDM
MDP
MEP
MediaLB
MHP
MIMO
MIS
MLBCLK
MLBDAT

GatewayHome Audio-Video Interoperability
Host Controller Interface - a Bluetooth interface
Hands-Free Unit - a Bluetooth interface
Human Machine Interface
Head Unit
Institute of Electrical and Electronics Engineers
Inter Frame Gap
Intelligent Network Interface Controller
Instance ID of a function blockIntellectual Property
Industrial Scientific Medical Band; unlicensed frequency band
International Telecommunications Union
Joint Photographic Experts Group
Joint Test Action Group
Logical Link Control and Adaption Protocol - a Bluetooth protocol
Local Area Networks
Light Emitting DiodeLEG OS8104 compatibility mode; pin of the NIC OS8104A
Low Frequency Effect
Logical Link Control
Low Level Driver
Link Manager Protocol - a Bluetooth protocol
Media Access Control
MOST Asynchronous Medium Access Control
Message Buffer Management
MOST Compliance Administrator
MOST Compliance Product List
Channel Resource Allocation Table
MOST Transceiver Control Service
MOST Compliance Supervisory Board
MOST Compliance Technical Group
MOST Compliance Test House
MOST Debug Message Module
MOST Data Packets
MOST Ethernet Packets
Media Local Bus
MOST High Protocol
Multiple Input-Multiple Output
Message Interface Service
MediaLB ClockMediaLB Data

C: Abbreviations 315

MLBSIG
MNS
MPEG
MPR
MRT
MSC
MSV
Mutex
NA
NAV
NB
NBEHC
NBMIN
NCE
NDIS
NIC
NTFS
OEC
OEM
OpCodesoPhy
OpType
OS
OSI
OUI
PAL
PAR_CP
PAR_SRC
PARC
PC
PCB
PCI
PCM
PCS
PDC
PIM
PLL
PM
PMA
PMMA
PMS
POF
ppm

MediaLB Signal
MOST NetServices KernelMoving Picture Expert Group
Maximum Position Register
MOST Routing Table
Message Sequence Chart(s)MOST Supervisor
Mutual Exclusion
Numerical Aperture
Navigation Device
NetBlock
NetBlock on EHC (cooperates with NBMIN)
Minimum NetBlock on INIC
Network Change Event
Network Driver Interface Specification
Network Interface Controller
Notification Service
Optical/Electrical Converter
Original Equipment Manufacturer
Operation Codes
optical Physical Layer
Operation TypeOperation System
Open Systems Interconnection Reference Model
Organizationally Unique Identifier
Protocol Adaption Layer
Control Port Parallel; pin of the NIC
Source Port Parallel; pin of the NIC
Xerox Palo Alto Research Center
Physical Channel
Printed Circuit Board
Peripheral Component Interconnect
Pulse Code Modulation
Plastic Clad Silica
Packet Data Channel
Personal Information Management
Phase-locked Loop
Port Message Protocol
Parked Member Address
Polymethyl Methacrylate
Port Message Service
Plastic Optical Fiberparts per million

316 C: Abbreviations
PWD
PWV
PXI
QA
QoS
RCLED
RBD
RFCOMM
RMCK
RMS
RTCP
RTP
RTR
SA
SCK
SCL
SCO
SCS
SDP
SH
SI
SIG
SIM
SNAP
SOP
SP
SR
SSO
STP
SX
SyncML
SW
TCU
TDM
TDMA
TP2.0
TSI
TV
UDS
UI
UJ
UPnP

Pulse Width Distortion
Pulse Width Variation
PCI eXtensions for Instrumentation; modular instrumentation
platform originally introduced in 1997 by National Instruments
Quality Assurance
Quality of Service
Resonant Cavity Light Emitting Diode
Ring Break Diagnostic
Radio Frequency Communication - a Bluetooth protocol
Recovered Master Clock of the NIC or INIC
Root Mean Square
Real Time Control Protocol
Real Time Transport Protocol
Remote Transmission Request
Super Audio by SonyClock Pin
Clock of the serial CP Interface; pin of the NIC
Synchronous Connection Oriented – a Bluetooth link
Synchronous Connection Service
Service Discovery Protocol - a Bluetooth protocol
Socket Handle
Step Index
Special Interest Group
Subscriber Identity Module
Sub Network Access Protocol
Start of Production
Source Port of the NIC
Streaming Data Receiver
Sudden Signal Off
Shielded Twisted Pair
Streaming Data Transmitter
Synchronization Markup Language
SoftwareTelephone Control Unit
Time Division Multiplexing
Time Division Multiple Accessproprietary Volkswagen Transport Protocol
Transport Stream Interface
Television Tuner
Unified Diagnostic Services
Unit Interval; shortest pulse in the data signal
Uncorrelated Jitter
Universal Plug-and-Play

C: Abbreviations 317

USB
UTP
vMSV
wADS
wAMS
wCMS
WLAN
wMCS
wSCM
www

Universal Serial Bus
Unshielded Twisted Pair
Virtual MOST Supervisor
Asynchronous Data Service Wrapper
Application Message Service Wrapper
Control Message Service Wrapper
Wireless Local Area Network
MOST Processor Control Service Wrapper
Socket Connection Manager Wrapper
World Wide Web

318

D

GlossaryAPI
The application programming interface is an interface which allows other programsto access a software element (e.g., communication interface).
Attenuation
The positive (decrease) or negative (increase) attenuation of a signal is usually
given in dB (decibel).
Biphase MarkBiphase mark code refers to a line code that differs slightly from the Manchester
code. There is always a transition at the start of a bit. A 1 has a transition at the
middle of the bit. For a 0, there is no transition until the end of the bit.
Bond Breakage
Bond breakage is an interruption of the wires that connect a chip electrically to thelead frame.
Boundary Descriptor
The boundary descriptor determines the rate of streaming and packet data within aframe.
BypassThe bypass is a function in the MOST Network Interface Controller. It is closed
during the initializing phase, in the case of a device error or when the device is deliberately switched off. It transmits all data arriving at the input (RX) directly to the
output (TX).
CavityA cavity is a hollow space in the pigtail.
Central Registry
The Central Registry is a table containing the function blocks existing in the system, as well as the logical addresses of the devices on which the function blocks are
implemented. It is implemented on the NetworkMaster.
Cladding
Cladding is the optical coat of the POF.
Coating
Coating is the exterior coating of the POF. Vehicle applications use a double exterior coating.

D: Glossary 319
Codec
Codec is a portmanteau word formed from the words coder and decoder. It refers to
a process or program for digitally coding and decoding data or signals.
ConnectionMaster
The function block ConnectionMaster manages the streaming channels in a MOST
system.
Control CommandControl commands are data packets for controlling the MOST system. They aretransmitted mostly on the Control Channel, but can also use the Packt Data Channel.
Controller
A Controller controls function blocks. It is often responsible for a specific functionin the MOST system (e.g., audio function).
Decentral Registry
The Decentral Registry is an image of the Central Registry (or of a section thereof)in a NetworkSlave, which accesses other function blocks in a MOST system.
Delamination
The disconnection of pottant and lead frame of an IC is referred to as delamination.
It is a characteristic damage after cyclic thermal stress.
Deployment
Deployment is the distribution of functions to the actual hardware structure of the
on-board electrical infrastructure.
DeviceA MOST device is a physical device that is connected to the MOST system via a
Network Interface Controller.
DeviceID
The DeviceID stands for a physical device or a group of devices in the network.
The DeviceID (RxTxAdr) can represent a node position address (RxTxPos), a logical address (RxTxLog) or a group address.
ErrataErrata is the complementary document of a specification in which errors are corrected or matters are clarified. In MOST specifications, it is used in compliancespecifications.
Extrusion
Extrusion (Latin: extrudere = to eject, to extrude) refers to a continuous process inwhich plastics are pressed through a nozzle.

320 D: Glossaryf(x) = f(f(x)), i.e., if the repeated application of a function is equivalent to the single
application.
FBlock Shadow
The FBlock shadow is an implementation concept in which the FBlock is controlled
via a proxy.
FerruleA ferrule is a guide tube which accommodates the POF fiber and forms the mechanical interface for fixing the fiber.
Flash Memory
Erasable/re-writable memory; in the automotive area the software of the micro controllers is usually filed in flash memories.
Frame
A frame is the basic data structure of the MOST data link layer which is transmitted
cyclically in the MOST ring. A frame carries data belonging to the Streaming
Channel, Packet Data Channel and the Control Channel.
Fresnel Losses
Losses occurring at the radiative transition between media of differing refractive indices are referred to as Fresnel losses.
Function Block or FBlock
A function block or FBlock is an object containing the interface, i.e., the methods
and properties, for controlling a specific application (e.g., a radio tuner or a telephone interface) or system service.
Function
Function is the generic term for the properties and methods of a function block.
Gateway
A gateway connects different data transmission systems. In this connection thecomplete communication stack of each system must be implemented (all existinglayers of the OSI model).
Golden Fiber
Golden fiber is the term for a reference standard (reference fiber).
Hygroscopic Material
Hygroscopic material is a material that absorbs moisture. If mishandled, it cancause problems during the welding process.
Idempotent
Idempotent refers to the property of a function or a method if the following applies:D: Glossary 321
Init Ready
The Init Ready event informs the application of the MOST system having changed
into NetInterface Normal Operation.
Leadframe
A thin layer of metal that has pre-stamped connecting pins and bond pads of integrated circuits (ICs) is referred to as a leadframe.
Light-off StateThe light-off state refers to the state in which the modulated signal is switched off
by any node. All nodes then change to the light-off state, pass to the NotOK system
state and and finally end in the NetInterface Off state.
Light-on State
Light-on describes the state in which the modulated signal is switched on.
Lock Event
The lock event is generated when the MOST Network Interface Controller could
synchronize steadily onto the signal for the first time or after an unlock event.
Lock
Lock refers to the TimingSlaves synchronizing onto the MOST signal.
MethodA method is a function of a function block by means of which an action is started,which then leads to a result after a specified period of time.
Mode Dispersion
Mode dispersion is the pulse broadening in optical fibers due to differing propagation constants of the modes or light beams.
NetBlock
NetBlock is a function block that is implemented in each device for administeringfunctions.
NetInterface
The NetInterface comprises the entire MOST interface consisting of the physicallayer, MOST Network Interface Controller and Network Service.
NetServices
See Network Service
Network Change Event (NCE)
A network change event occurs if the number of active nodes in the ring changes,
e.g., if during the start-up a device needs more time for the boot-up process andcloses its bypass late or if a node fails or changes into sleep mode.
Network Scan
See: system scan

322 D: Glossary
Network Service
The Network Service is the driving layer that must be implemented in each deviceof a MOST system for controlling the MOST Network Interface Controller. Applications and system services access the MOST system via the Network Service.
NetServices is the trade name for the implementation of the SMSC Network Service.
NetworkMaster
The function block NetworkMaster controls the system state and manages the Central Registry.
Numerical Aperture
The numerical aperture describes the aperture angle in optical fiber technology, under which optical radiation can be coupled into an optical fiber.
Operation
The MOST standard defines specific standard operations that can be used for properties and methods.
Packet Data
Packet data are large data packets that are transmitted on the Packet Data Channel,e.g., when tunneling a TCP/IP connection via the MOST bus.
PigtailA two-fiber cable with a POF connector pre-assembled at one end, consisting of an
optical transmitter, an optical receiver, two POF fibers and the mechanical adaptation is referred to as a pigtail.
PLL (phase locked loop)
A phase locked loop is a control circuit that tries to keep an oscillator in the phaseof the input frequency by means of phase detection.
POF (polymeric optical fiber, plastic optical fiber)
A polymeric optical fiber is a plastic optical fiber for transmitting data. The core of
the POF is mostly made of polymethyl methacrylate (PMMA). The optical fiber isoften coated in order to achieve a higher stability.
PowerMaster
The PowerMaster is responsible for booting up and shutting down a MOST systemand supervises its power management.
Property
A property is a function that corresponds to a specific property of a function block.
The properties serve to query or change the current state of a function block
QuadletA quadlet consists of 4 bytes.

D: Glossary 323
Recombination
Recombination refers to the combination of positive and negative charge carriers(ions, electrons) to form an electrically neutral product (atom, molecule).
RxTxAdrGeneric term for the three address types of a MOST node: logical node address(RxTxLog), node position address (RxTxPos) or group address. The transmitter address is TxAdr and the receiver address RxAdr.
RxTxLog
RxTxLog is the logical address. TxLog refers to the logical transmitter address and
RxLog to the receiver address. It may only appear once in the MOST ring.
RxTxPos
RxTxPos describes the node position address of a node. It depends on the positionof the node in the ring. TxPos refers to the transmitter and RxPos to the receiver address.
S/PDIF
S/PDIF stands for Sony/Philips Digital Interface. It is a bus and interface specification for transmitting digital audio signals between different devices and is also referred to as Sony/Philips Digiconnect Format, S/P-DIF or TOSLINK.
Slave
A slave is a function block that is controlled by a Controller, or the device in which
it is implemented.
SPY Mode
The SPY mode is an operational mode for analysis tools. They are not visible in the
network but can listen into the entire bus communication.
Streaming Data
Streaming data can be audio or video data, for example. In MOST, they are transmitted on the Streaming Data Channel.
Substitution Method
The substitution method is a comparative measuring method, in which the characteristics of a fiber under test are compared to the respective characteristics of a reference fiber.
System Scan
System scan describes how the function block configuration data of the NetworkSlaves are read by the NetworkMaster. This is also often referred to as network
scan.
System State
During normal operation the system is in the OK state, during the initialization or in
the case of an address conflict the system is in the NotOK state.

324 D: GlossarytDiag_Signal
Time a TimingSlave node waits for activity at its Rx input before switching to ringbreak TimingMaster mode.
TimingMaster
The TimingMaster generates the system clock for the frames and blocks. The TimingSlaves synchronize onto the system clock.
Transceiver
Transceiver is a portmanteau word formed from the words transmitter and receiver.
tSSO_ShutDown
Time between setting the Shutdown Flag and switching off the signal at the output.
UCritical
Critical voltage UCritical is the limit at which the application might no longer worksafely but where communication is still possible. In that case, a source must routezeros and a sink must secure its output signals. The Mute property remains unchanged. In case of a recovery, the output signals can be restored immediately.
ULow
Low voltage ULow is a device specific limit, where even the NetInterface no longer
works reliably, so even communication cannot be maintained. If ULow is reached,
the device switches off the modulated signal and switches to DevicePowerOff
Mode. The device stays in DevicePowerOff mode, even if the supply voltage recovers.
Unlock Event
The unlock event is generated for the application by the Network Service if the
MOST Network Interface Controller can no longer generate a stable clock from the
PLL.
UnlockA TimingSlave that can no longer synchronize with its PLL to the input signal at
the Rx input detects an unlock.
Wave Soldering
Wave soldering is a processing procedure in electronics production. Printed circuitboards are passed across a wave of molten solder, creating a reliable connection between the PCB and the component.

325

E

Bibliography[AppN Mig]

Application Note MOST150 Migration, Rev 1.0; 05/2009;
MOST Cooperation[Bluetooth]Specification of the Bluetooth System-Profile, Version 1.1, 02/
2001; Special Interested Group Bluetooth[Burton 2004]

Automotive Testing of Automotive Telematics Systems using
TTCN-3, Simon Burton, Andre Baresel, Ina Schieferdecker,
Proceedings of the 3rd Workshop on System Testing and Validation (SV04), December 2004.

[Cat 02]

MOST Function Catalog Read Me First; Rev 1.0; 12/2002;
MOST Cooperation[Com_ePhyL]

MOST ePHY Compliance Test Spec (with ePhy Compliance
Test Patterns) Rev 1.0; 06/2006; MOST Cooperation[ComPhyL 1.0]

MOST Specification MOST Compliance Test of PhysicalLayer; Rev 1.0; 12/2003; MOST Cooperation[ComPhyL 150]

MOST150 oPhy Compliance Measurement Guideline; Rev.
1.1; 08/2010; MOST Cooperation[ComPhyL_Err]

ERRATA MOST Compliance Test of Physical Layer; Rev 1.0,
05/ 2006; MOST Cooperation[ComPhyLP 1.0]

MOST Compliance Verification Procedure Physical Layer;
Rev. 1.0; 07/2004; MOST Cooperation[ComPhyLP 150]

MOST150 oPhy Compliance Verification Procedure – PhysicalLayer; Rev. 1.1; 07/2010; MOST Cooperation[ComPhyLP_Err] ERRATA MOST Compliance Verification Procedure PhysicalLayer; Rev. 1.1; Rev. 1.0; 07/2005; MOST Cooperation[ComProf]

MOST Profile Compliance Test Specification; Rev 1.0;
10/2005; MOST Cooperation[ComReq]

MOST Specification - MOST Compliance Requirements, Rev
2.1; 04/2009; MOST Cooperation[ContProt]

MOST Content Protection Scheme DTCP Implementation;Rev. 3.0; 08/2009; MOST Cooperation

326 E: Bibliography[Core]MOST Core Compliance Test Specification; Rev 1.1.01;
06/2005; MOST Cooperation[Core_Err]

ERRATA MOST Core Compliance Test Specification; Rev
1.3; 07/2009; MOST Cooperation[Dau 01]

Daum W. et al.: „POF – optische Polymerfasern für die
Datenkommunikation", Springer Verlag, 2001

[DPA]

Diagnostic Protocols Adaptation Specification, Rev. 1.0.1;
08/2009; MOST Cooperation[DS 8104]

OS8104 – MOST Network Transceiver – Final Product Data
Sheet; Jan. 2003; www.smsc-ais.com[DS FCM110]

MOST Fiber Optic Transceiver, FCM110R/ FCM110D, Firecomms Ltd.

[DTD Cook]

MOST DTD Cookbook; Rev 1.2; 12/2009; MOST Cooperation[DynSpec]

MOST Dynamic Specification; Rev 3.0; 07/2008; MOST Cooperation[ECL]

Electrical Control Line, Rev. 1.0.1; 08/2009; MOST Cooperation[ETS 300 406]

ETS 300 406 „Methods for Testing and Specifications (MTS);
Protocol and Profile Conformance Testing Specifications;Standardization methodology” http://portal.etsi.org/mbs[ETSI 2003]ETSI ES 201873: The Testing and Test Control Notation
TTCN-3, Part 1 (Core Language), Part 2 (Tabular Format), Part
3 (Graphical Format), Part 4 (Operational Semantics), Part 5(TTCN-3 Runtime Interface), Part 6 (TTCN-3 Control Interfaces), Sophia-Antipolis, France, October 2003.

[FBADiskPl 2.4]

MOST FunctionBlock AudioDiskPlayer; Rev 2.4; 09/2003;
MOST Cooperation[FBAmFmT 2.4]

MOST FunctionBlock AmFmTuner, Rev 2.4.2; 09/2003;
MOST Cooperation[FBAudioA 2.4]

MOST FunctionBlock AudioAmplifier; Rev 2.4.2; 09/2003;
MOST Cooperation[FBAuxIn 3.5]

MOST FunctionBlock AuxIn, Rev 3.5; 10/2008; MOST Cooperation[FBCM]MOST FunctionBlock ConnectionMaster; Rev 3.0.1; 09/2010;
MOST Cooperation

E: Bibliography 327[FBET]MOST FunctionBlock EnhancedTestability; Rev 3.0; 8/2010;
MOST Cooperation[FBGenPl 2.5]

MOST FunctionBlock GeneralPlayer; Rev 2.5.1; 01/2008;
MOST Cooperation[FBVehicle 1.6]

MOST FunctionBlock Vehicle, Rev 1.6 09/2002; MOST Cooperation[FBX Cook]

MOST FIBEX Cookbook; Rev 1.0; 03/2009; MOST Cooperation[Found 04]

MOST Foundation Training; Training Handout; Oasis SiliconSystems; 2004

[GADV]

4CS, GADV Gmbh, http://www.gadv.de/[GenFB]

MOST FunctionBlock GeneralFBlock; Rev 3.0.2; 09/2010;
MOST Cooperation[Gus 98]

D. Gustedt, W. Wiesner: „Fiber-Optic-Übertragungstechnik",
Sende- und Empfangsgrundlagen, Franzis-Verlag, 1998

[HFP 1.5]

Hands-Free Profilewww.bluetooth.org[ISO 14229]

Road vehicles -- Unified diagnostic services (UDS), ISO
14229. ISO, Geneve 2009[ISO 14230]

Road vehicles -- Diagnostic systems -- Keyword Protocol 2000,
ISO 14230, Geneve 1999/2000[ISO 9646]

Information Technology, Open Systems Interconnection, Conformance Testing Methodology and Framework. International
Standard IS-9646. ISO, Geneve 1991

[ITUZ120]

Z.120: Message Sequence Charts, MSC-2000, Geneva, Switzerland, October 1999.

[Lehmann 2000]

Test Case Design by Means of the CTE XL. E. Lehmann;
Wegener, J Proceedings of the 8th European International Conference on Software Testing, Analysis & Review (EuroSTAR
2000), Kopenhagen, Denmark, December 2000.

[MAMAC]

MAMAC Specification; Rev. 1.1; 12/2003; MOST Cooperation[MediaLB]Media Local Bus Specification; Physical Layer and Link Layer;
Version 3.0; SMSC; www.smsc-ais.com[Mercury]

Test
Director,
Mercury
http://www.testerlyzer.de/

1.5;

HFP1.5_SPEC;

Interactive

2005-11-25

Limited,328 E: Bibliography[MHP]

MOST High Protocol Specification; Rev 2.3; 12/2008; MOST
Cooperation[MNS L1 1.x]

MOSTNetServices; Basic Services (Layer I); Programmers’
Library for Interfacing to MOST User Manual and Specification of Layer I; Preliminary Version 1.10; www.smsc-ais.com[MNS L1 2.x]

MOST NetServices Layer I; Wrapper for INIC; V2.1.x; User
Manual/Specification; www.smsc-ais.com[MNS L1 3.x]

MOST NetServices Layer I; Wrapper for INIC; V3.x; User
Manual/Specification; www.smsc-ais.com[MNS L1 Exa] MOST NetServices; Layer 1 Example; Version 1.10-01;
www.smsc-ais.com[MNS L2]

MOST NetServices Layer II; User Manual/Specification; Rev.
1.10.x / 2.1.x; www.smsc-ais.com[MOST 2.4]

MOST Specification; Rev 2.4; 05/2005; MOST Cooperation[MOST 2.5]

MOST Specification; Rev 2.5; 10/2006; MOST Cooperation[MOST 2003]

Empfehlungen für Optische MOST Interfaces in Automotive
Anwendungen (Version 1.0), MOST Co, Audi AG, BMW AG,
DaimlerChrysler AG, RMCTech GmbH, 2003.

[MOST 3.0]

MOST Specification; Rev 3.0 E2; 07/2010; MOST Cooperation[MOST AARSMD] Automotive Application Recommendation for optical MOST
Components - Surface Mount Device (SMD) Rev. 1.0,
10/2010, MOST Cooperation[MOST AARTHM] Automotive Application Recommendation for optical MOST
Interfaces, Rev. 3.0-06, 06/2009, MOST Cooperation[MOST AppTF]

Application Note POF Transfer Function, Rev. 1.0, 03/2009,
MOST Cooperation[MOST BaPhy]

MOST Physical Layer Basic Specification, Rev. 1.0, 12/2008,
MOST Cooperation[MOST ePhy]

MOST Specification of Electrical Physical Layer, Rev. 1.0, 12/2004, MOST Cooperation[MOST Org]

MOST Cooperation Organizational Procedures Rev 3.5
04/2007; MOST Cooperation[MOST Phy150]

MOST150 oPHY Automotive Physical Layer
Specification, Rev. 1.1, 05/2010, MOST CooperationSub-E: Bibliography 329[MOST Stream]

Stream Transmission Specification Rev. 3.0. 08/2009, MOST
Cooperation[MSC]

MOST MSC Cookbook; Rev 1.2; 08/2005; MOST Cooperation[NetBlock]

MOST FunctionBlock NetBlock; Rev 3.0.1; 09/2010; MOST
Cooperation[Optitas]

Tool4M-XL, Optitas GmbH, http://www.optitas.de/[PBAP]

Phone Book Access Profile; PBAP_SPEC; www.bluetooth.org[PFLNet]MOST NetServices API – The Interface to the MOST Network;
Product Flyer 04/03; SMSC; www.smsc-ais.com[Por 2004]

Vernetzte Systeme im Cayenne; Porsche
Magazine; Ausgabe 01/2004; S. 12 - S.15

[Praesideo]

Praesideo data sheet; www.bosch-sicherheitsprodukte.de (Nov.
2010)[RFC 2616]

Hypertext Transfer Protocol – HTTP/1.1; Juni 1999; R. Fielding, J. Gettys, H. Frystyk, L. Masinter, P. Leach, T. BernersLee[Ruetz]Testerlyzer,
Ruetz
http://www.testerlyzer.de/[SAP]

SIM Access Profile; SAP_SPEC; www.bluetooth.org[Schr 01]

A. Schramm, ”MOST Investigations at BMW, Migration or
Evolution“, Annual All Members Meeting, Frankfurt, Germany, 11th March 2008

[Schr 02]

A. Schramm, “MOST in der dritten Generation: MOST150
Systemaspekte und Migrationsalternativen“, ElektronikPraxis;
8th August 2008

[SMSC]

Optolyzer G2, SMSC, Automotive Infotainment Systems
GmbH, www.smsc-ais.com[Stream]

MOST Specification for Stream Transmission; Rev. 3.0;
07/2010; MOST Cooperation[Tutorial]

MOST Tutorial-CD; MOST Cooperation[Vector]

CANoe- Development and Test Tool for CAN, LIN, MOST,
FlexRay, Ethernet and J1708, www.vector.com[Vog 02]

E. Voges, K. Petermann: „Optische Kommunikationstechnik“,
Springer Verlag, 2002

Engineering

TechnologiesGmbH,330 E: Bibliography[Wei 99]

Weinert A.: „Plastic Optical Fibers“, Publicis MCD Verlag,
Erlangen, 1999

[Z.120 04]

ITU-T Message Sequence Chart (MSC); Geneva; (04/2004);
http://www.itu.int[Z.120 99]

ITU-T Recommendation Z.120 (MSC2000) Message Sequence
Chart (MSC); Geneva; (11/1999); http://www.itu.int[Z.120AB 98]

ITU-T Message Sequence Chart (MSC) Annex B: Formal sematics of Message Sequence Charts; Geneva; (04/1998);
http://www.itu.int[Z.120C1 01]

ITU-T Z.LC-Text: Recommendation Z.120 Corrigendum 1;
Geneva; (11/2001); http://www.itu.int

331

Index
Acceptance angle, 122
AM/FM tuner, 81
AmFmTuner, 81, 306
Amplifier, 80
API, 318
Application Framework, 30, 49
Application Protocol, 29, 51
Application Recommendation, 48
Array, 68
Attenuation, 128, 141, 144, 273, 318
Audio amplifier, 30, 80
Audio Streaming, 298
 Analog Dolby Surround Pro Logic, 298
 Analog Dolby Surround Pro Logic II, 298
 Digital Theatre System (DTS), 299
 Dolby Digital, AC3, 298
 Logic 7, 299
 MPEG-2, 299
 Stereo, 298
AudioAmplifier, 30, 80, 159
AudioDiskPlayer, 80, 159
AuxIn, 81
Bandwidth, 41, 74, 88, 89, 93, 97, 129
Biphase Mark, 318
Bit rate, 37, 89, 311
BitSet, 68
BlockWidth, 74
Bond Breakage, 318
BoolField, 68
Boundary Descriptor, 88, 318
Broadcast address, 52, 109, 111
Broadcast message, 102, 111
Bus load, 249
Bypass, 39, 110, 158, 318
Cavity, 318
CD changer, 30, 39, 80, 186
CD Player, 80
Central gateway, 281
Central Registry, 40, 46, 72, 156, 185, 223,
318
Cladding, 122, 148, 274, 318
Cleaving, 149
Coating, 318
Codec, 39, 319
Coding errors, 169
Command Interpreter, 184
Compliance Level, 229
Compliance Process, 229
Compliance Test, 78, 229, 248

Compliance Test House, 230
Compliance Verification, 27
ConnectionLabel, 74
ConnectionMaster, 39, 41, 53, 73, 76, 77,
94, 190, 236, 285, 319
Connections, 200
Container, 68
Control Channel, 35, 115
Control Command, 319
Control Port, 206, 214
Controller, 32, 44, 50, 63, 83, 319
Converter, 226
Cookbook, 48
Cooperation contract, 24
Core Compliance, 230
Core Compliance Test, 234
Crimping, 127, 271
Critical Unlock, 168
Data Link Layer, 34
Data link layer protocol, 97, 109
Decentral Registry, 160, 185, 319
Declaration of Compliance, 231
Delamination, 319
Deployment, 319
Device, 319
Device Address, 52
DeviceID, 52, 319
Diagnosis, 45
Diagnostic Adaptation Protocol, 171
Digital Transmission Content Protection, 42
DoC, 231
Double ring, 38
Driver assistance, 301
DTCP, 42
Dynamic Device Behavior, 45
DynamicArray, 68
EHC, 39
EHCI-Attached, 204
EHCI-Protected, 203
EHCI-Semi-Protected, 204
Electrical Control Line, 169
Electrical Physical Layer, 38, 152
Electromagnetic Compatibility, 122Electromagnetic Interference, 122
EMC, 37, 122, 152, 243
EMI, 122
EnhancedTestability, 47, 53, 71, 183
Enumeration, 68
Errata, 319

332 Index
Errata Sheets, 47
Error Management, 45
ErrorCode, 64, 65
ErrorInfo, 65
ET, 71
Ethernet MAC address (only MOST150),
109
Ethernet MAC address filter, 117
Executing Method, 61External Host Controller, 39, 191
 Interface State Machine, 203
Extinction ratio, 139, 142
Extrusion, 319
Eye diagram, 152
FBlock, 49, 320
 AmFmTuner, 81 AudioAmplifier, 80 AudioDiskPlayer, 80
 AuxIn, 81
 ConnectionMaster, 73
 EnhancedTestability, 71
 NetBlock, 70
 NetworkMaster, 71
 PowerMaster, 73
 Vehicle, 78
FBlock Identifier, 53
FBlock Shadow, 320
FBlock Vehicle, 281
FBlock Viewer, 223
FBlockID, 53
FBlockIDList, 155
Ferrule, 127, 149, 270, 320
Fiber Optic Receiver, 38
Fiber Optic Transceiver, 38
Fiber Optic Transmitter, 38
FktID, 54
Flash Memory, 320
FOR, 38
FOT, 38
FOX, 38
Frame, 320
Frame Control, 89
Frame rate, 135
Fresnel losses, 273, 320
Function, 31
Function block, 49, 320
Function class Array, 68 BitSet, 68 BoolField, 68
 Container, 68
 DynamicArray, 68 Enumeration, 68
 LongArray, 69
 Map, 69

 Number, 67
 Record, 68
 Sequence Method, 69
 Sequence Property, 69
 Switch, 67
 Text, 67
 Trigger, 69
 Unclassified Method, 67
 Unclassified Property, 67
Function Identifier, 54
Function model, 44
Functional address, 50, 53
Functional addressing, 172
Gateway, 226, 320
GeneralFBlock, 79
GeneralPlayer, 80
GMI, 238
Golden Fiber, 274, 320
Golden MOST Implementation, 238
Group address, 70, 109
Guideline, 48
Header, 268
Headunit, 293
High-Level MSC, 309
HMI, 32, 186
Hub, 37, 226
Human Machine Interface, 32
Hygroscopic Material, 320
Idempotent, 320
INIC, 37, 101, 111, 192
 Peripheral interfaces, 195
INIC Connectivity, 197
INIC Control Messages, 199
INIC Family, 194
INIC Message Interface, 198
INIC Remote Viewer, 226
Init Ready, 321
Inline connector, 150
Instances of FBlocks, 54
InstID, 54
Intelligent Network Interface Controller, 37
Jitter, 136, 233
Laser diode, 130, 148
Laser welding, 125, 271
Leadframe, 321
Light off, 139
Light-off State, 142, 321
Light-on State, 321
Limited Physical Layer Compliance Test,
234
Lock, 36, 321
Lock Event, 321
Logical node address, 109
LongArray, 69
MAMAC, 34, 48, 112

Index 333
Map, 69
Master Delay Tolerance, 146
Maximum position register, 155
MCA, 230
MCPL, 232
MCSB, 230
MCTG, 231
MCTH, 231
Media Interface Devices, 295
Media Local Bus, 208
MediaLB, 208
MediaLB Analyzer, 227
Message Sequence Chart, 33, 60, 305
 Actions, 308
 Condition, 308
 Environment, 307
 High-Level MSC, 309
 Instances, 306
 Messages, 307
 Timer, 308
Message Sequence Chart Editor, 220
Message Type, 101
Method, 31, 54, 321
MHP, 112
Mode dispersion, 123, 321
MOST Asynchronous Medium AccessControl, 48
MOST based Infotainment First generation, 290
 Fourth generation, 292
 Second generation, 290
 Third generation, 291
MOST Certification Test Process, 229
MOST Compliance Administrator, 230
MOST Compliance Product List, 232
MOST Compliance Requirements, 46
MOST Compliance Supervisory Board, 230
MOST Compliance Technical Group, 231
MOST Compliance Test House, 231
MOST Compliance Verification Procedure –Physical Layer, 47
MOST Content Protection Specification, 48
MOST Control Messages, 199
MOST Core Compliance Test Specification,
47
MOST Data Packets, 117, 199
MOST device, 38
MOST Dynamic Specification, 46
MOST Ethernet Packets, 117
MOST Frame Control Channel, 35
 Packet Data Channel, 35
 Streaming Data Channel, 34
MOST function block, 30, 66
MOST function catalog, 77

MOST High Protocol, 32, 48, 112
MOST Interface Controller, 191
MOST IP (Intellectual Property), 229
MOST NetServices, 175
MOST Profile Compliance Test
Specification, 48, 236
MOST Profile ConnectionMaster
Compliance Test Specification, 48
MOST ring, 37
MOST Stream Transmission Specification,
48
MOST150, 37, 90
MOST150 Evolution Concept, 257
 Hardware, 258
 Software, 259
MOST150 frame, 91
MOST150 reference platform, 252
MOST25, 36, 37
MOST25 frame, 87
MOST25/MOST150 Bridge Concept, 261
 Addressing, 262
 Network Management, 263
 PCM Data Bridging, 265
MOST50, 37, 89
MOST50 frame, 90
MPEG, 42
MPR, 155
MSC, 33, 246
NCE, 321
NetBlock, 40, 53, 70, 156, 183, 187, 199,
321
NetBlockMin, 199
NetInterface, 321
NetServices, 321
NetServices MiniKernel, 199
Network Change Event, 71, 321
Network Interface Controller, 37, 213
NetworkMaster Shadow Module, 186
Network Scan, 321
Network Service, 30, 34, 53, 72, 109, 112,
175, 322
NetworkMaster, 40, 53, 71, 155, 159, 185,
186, 190, 322
NetworkSlaves, 41
NIC, 37, 97, 101, 111, 193, 213
Node Position, 109
Node position address, 109, 155
Notification, 63
Notification Matrix, 63, 161, 184
Notification Mechanism, 63, 161
Notification Service, 184
NotificationMatrixSize, 46
Number, 67
Numerical aperture, 123, 322
Offline analysis, 223

334 Index
Online analysis, 223
Operation, 322
 AbortAck, 63
 Decrement, 61
 Error, 65
 ErrorAck, 65 Get, 60
 GetInterface, 69
 Increment, 61
 Interface, 69
 ProcessingAck, 62
 ResultAck, 62 Set, 60 SetGet, 61
 StartAck, 62
 StartResultAck, 62
 Status, 60
Operation Type, 55
Optical fibers, 122
 Acceptance angle, 122
 Mode dispersion, 123
 Numerical aperture, 123
 Pulse distortion, 123
Optical Physical Layer, 37
Optical power, 121, 130, 139
Optical power budget, 143
Optical spectrum, 142
OPType, 55
Over-Temperature, 164
Packet data, 34, 322
Packet Data Channel, 34, 35, 115
Parameter type
 BitField, 57
 Boolean, 57
 Classified Stream, 58
 Enum, 58
 Short Stream, 58
 Signed/Unsigned Byte, 58 Signed/Unsigned Long, 58
 Signed/Unsigned Word, 58
 Stream, 58
 String, 58
Parity Bit, 89
PCM, 42, 286
PCS, 148
Peaking, 130
Phase Locked Loop, 322
Physical addressing, 172
Pigtail, 268, 322
 µPigtail, 267
PIN photodiode, 131
Plastic Optical Fiber, 37, 122, 322
PLL, 35, 88, 322
POF, 37, 122, 322
Polymer Clad Silica, 148

Polymer fibers
 Bending radius, 127
 Buffer, 125 Optical attenuation, 126
 PMMA, 125
 Polycarbonate fibers, 126
 Structure, 125
Polymer Fibers, 124
Polymeric Optical Fiber, 322
Port Message Protocol, 202
Ports, 200
Position, 68
 PosX, 68
 PosY, 68
Power Management, 46, 178, 212
Power-Down, 162
PowerMaster, 40, 53, 73, 162, 190, 322
Powertrain, 281
Profile Compliance Tests, 236
Property, 31, 54, 322
Pulse Code Modulation, 286
Pulse distortion, 123
QoS IP channels, 119
Quadlet, 88, 89, 91, 322
Radio Tuner, 81
RCLED, 130
Recombination, 323
Record, 68
Remaining Bus Simulation, 219
Repeater, 226
Reserved, 53
Ring break diagnosis, 167
Routing Engine, 94
RxTxAdr, 323
RxTxLog, 109, 323
RxTxPos, 109, 323
S/PDIF, 323
Sample rate, 89, 286, 310
Sequence Method, 69
Sequence Property, 69
Shared Packet Data Channel, 119
Shutdown, 73, 162, 178
SinkNr, 74
Slave, 32, 50, 323
Socket Connection Manager Wrapper, 182
Sockets, 200
Sound system, 296
Source Port, 214
SourceNr, 74
SPI port, 208
SPY Mode, 323
Start-up, 71, 178
Stream cases, 58
Stream signals, 58
Streaming connection, 74

Index 335
Streaming data, 34, 323
Streaming Data Channel, 34
Streaming port, 207
Stress tool, 223
Substitution Method, 323
Sudden Signal Off, 163, 163
Switch, 67
Synchronous data, 94
System FBlock, 69
System Master, 44
System scan, 71, 323
System State, 323
tDiag_Signal, 324
TDM, 94
Temperature stability, 271
Test case, 232, 241
Test process, 241
 Risk analysis, 241
 Test design, 241
 Test evaluation, 242
 Test implementation, 242
 Test management, 242
Text, 67
Time Division Multiplexing, 94
TimingMaster, 35, 70, 71, 88, 110, 110, 146,
167, 234

TimingSlave, 35
Total reflectance, 122
Transceiver, 129, 324
Transformer, 153
Transport Stream Interface, 208
Trigger, 69
tSSO_ShutDown, 324
UCritical, 324
ULow, 324
Unclassified Method, 68
Unclassified Property, 67
Undervoltage, 164
Unlock, 36, 324
Unlock and Critical Unlock, 163
Unlock Event, 324
VCSEL, 148, 149
Vehicle, 78
Video standards, 300
Video Streaming, 299
Wake-up, 40, 71, 234
Watchdog, 205
Wave Soldering, 324
Working Group, 26
XML, 31, 46, 221

65061-8 U1+U4_R25mm

14.01.2011

10:12 Uhr

Seite 1FRANZISELECTRONICS LIBRARY
THE AUTOMOTIVEMULTIMEDIA NETWORKMOST (Media Oriented Systems Transport) isa multimedia network technology developed
to enable an efficient transport of streaming,
packet and control data in an automobile.
It is the communication backbone of an

infotainment system in a car. MOST can also
be used in other product areas such as driverassistance systems and home applications.

MOST is a communication system with a new, flexible architecture, used bymany different manufacturers. It is the most widely used multimedia
network in the automotive industry.
In 2010, more than 100 car models are already equipped with MOST Technology. MOST defines the protocol, hardware, software and system layersthat are necessary for the high-performance and cost effective transport ofrealtime data in a shared medium. MOST Technology is developed andstandardized within the MOST Cooperation through a joint effort of carmakers and their suppliers. It is now evolving into a third generation with
MOST150 Technology.
The MOST Cooperation commissioned this updated book with the goal of
making it easier to understand and use MOST Technology. The authors of
the book work for carmakers, suppliers and scientific institutes. The
emphasis of the first part of the book is the MOST standard itself. After describing the organization of the MOST Cooperation, the general communication architecture of an automobile using MOST is presented. Then thechapter “Survery of the System Architecture” gives an overview of MOST
Technology. The most important aspects of the technology are then presented
in detail in subsequent chapters.

EDITOR: PROF. DR. ING. ANDREAS GRZEMBA

THE AUTOMOTIVEMULTIMEDIA NETWORKFROM MOST25 TO MOST150

The book is aimed at engineers at suppliers and carmakers that want to getstarted with MOST Technology. It also provides an overview of an effective
communication architecture to interested engineers outside the automotive industry.

EUR 49,95 [D]FRANZISISBN 978-3-645-65061-8

Visit our website: www.franzis.de