§I
`
`I I
`
`Open Systems and the Corresponding Interfaces
`for Automotive Electronics
`
`OSEKNDX
`
`Network Management
`
`Concept and Application Programming Interface
`
`Version 2.5 1
`
`3 1st of May 2000
`
`This document is an official release and replaces all previously distributed documents. The OSEK
`group retains the right to make changes to this document without notice and does not accept liability
`for enors. All rights reserved. No part of this document may be reproduced, in any fonn or by any
`means, without permission in v.•riting from the OSEKNDX steering committee.
`
`Page 1
`
`###by OSEKIVDX
`
`NM Concept & API 2. 51
`
`PAGE 1 OF 139
`
`BMW EXHIBIT 1009
`
`

`

`Open Systems and the Corresponding Interfaces
`for Automotive Electronics
`
`81
`
`l l
`
`Table of Contents
`
`Sunnnary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
`
`1.
`
`Scope of the OSEK Network Management ............. .... ..................... .... ..................... .... .. 6
`
`2. Direct Network Managernent. ............ .... ..................... .... ..................... .... ..................... .. 8
`
`Concept .... .... ..................... .... ..................... .... ..................... .... ..................... .... ...... 8
`2.1.
`2.1. 1. Node Monitoring ................... .... ..................... .... ..................... .... ..................... .. 8
`2.1.2. Addressing ..................... .... ..................... .... ..................... .... ..................... .... .... 10
`2.1. 3. NM Iruiastructure for Data Exchange ..... ............. .... ............. .... ............. .... ....... 11
`2.1.4. Standard Functionality ... ............. .... ............. .... ............. .... ............. .... ............. .. 11
`2.1. 5. Configuration Management ..................... .... ..................... .... ..................... .... .... 12
`2.1.5.1. Network Configurations .................. .... ..................... .... ..................... .... .... 12
`2.1.5.2. Detection of a Node in Fault Condition .................... .... ..................... .... .... 12
`2.1.5.3.
`Internal Network Management States ............... ................. ................. ....... 13
`2.1.6. Operating Modes ........... .... ..................... .... ..................... .... ..................... .... .... 15
`2.1.7. Network Enor Detection and Treatment ..... .... ............. .... ............. .... ............. ... 15
`2. 1.8. Support ofDiagnostic Application .. ..... ..... ..... ..... ..... ..... ..... ..... .......................... 16
`2.2. Algorithms and Behaviour ..... ................. .... ................. .... ................. .... ................ 16
`2.2. 1. Communication of the Network Management System .. ............. .... ................. ... 16
`2.2. 1.1. Network Management Protocol Data Unit.. .......... .... ................. .... ............ 16
`2.2. 1.2. Addressing Mechanisms used by the Network Management.. ..... .... ............ 18
`2.2.2. NM Infi·astructure for Data Exchange ......... .... ................. .... ................. .... ........ 20
`2.2.3. Standard Tasks .................. .... ............. .... ................. .... ................. .... ................ 21
`2.2.3.1. Network Management Parameters ................ .... ................. .... ................. ... 21
`2.2.3.2. Network Status .. .... ................. .... ............. .... ................. .... ................. .... ... 22
`2.2.3.3. Extended Network Status ........ .... ................. .... ................. .... ............. .... ... 23
`2.2.4. Configuration Management ............. .... ................. .... ............. .... ................. .... ... 24
`2.2.4.1. Timing Reference ... .... ..................... .... ..................... .... ..................... .... .... 24
`2.2.4.2. Monitoring Counter ....... .... ..................... .... ..................... .... ..................... 25
`2.2.4.3. State transition diagram .. .... ..................... .... ..................... .... ..................... 25
`2.2.4.4. Particularities Regar·ding Implementation .......... ............. .... ............. .... ....... 29
`2.2.5. Example: Skipped in the logical ring .... ............. .... ............. .... ............. .... ........... 32
`2.2.6. Example: Logical Successor ... ..................... .... ..................... .... ..................... .... 34
`2.2.7. Operating Mode ............. .... ..................... .... ..................... .... ..................... .... .... 35
`2.2.7.1. NMActive - NMPassive .................. .... ..................... .... ..................... .... .... 35
`2.2.7.2. NMBusSleep - NMAwake ............... .... ..................... .... ..................... .... .... 36
`2.2.8. Fusion of Configuration Management and Operating Modes ..................... .... .... 40
`
`Page2
`PAGE2 OF 139
`
`### by OSEKIVDX
`
`NM Concept & API 2.5 1
`
`

`

`OSEKNDX
`
`Network Management
`Concept and Application Programming Interface
`
`2.2.8.1 . State Dia.grruns .................................. ........................ ................................ 40
`2.2.8.2. SDL DiagralllS .................................. ........................ ................................ 46
`2.2.9. Alru1ns inside the Network Management ........ ........................ ........................... 57
`2.2.9.1. Rules to design the a.lanns T Typ and TMax .................... ................................ 57
`2.2.9.2. Rules to design the a.lrum TEnor .......... ........................ ................................ 59
`2.2.9.3. Rules to design the a.lrum T waitBussteep .. ........................ ............................ .... 59
`2.2.9.4. Design of a. syste1n ............................ ........................ ................................ 59
`2.2.9.4.1 . Worst case .................................... ........................ ........................... 60
`2.2.9.4.2.
`Example .................................... ....................... ............................... 60
`
`3.
`
`Indirect Network Management ....................................... ........................ ...................... 61
`
`3.1 . Concept .. ...................................................... ........................ ................................ 61
`3.1 .1 . Node Monitoring ........................................... ........................ ........................... 61
`3. 1.1 . 1. Node states .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . 61
`3.1 .1 .2. Extended Node states ......................... ........................ ............................... 62
`3.1 .2. Configuration-Management ....................... ....................... ................................. 62
`3.1 .2.1 . Configuration .................................... ........................ ................................ 62
`3.1 .2.2. Extended Configuration ...................... ........................ ............................... 63
`3.1 .3. Standru·d Task .................................................. ........................ ......................... 63
`3.1 .3.1 . Network status .................................. ........................ ................................ 63
`3.1 .3.2. Extended network status .................... ........................ ............................... 63
`3.1 .4. Monitoring Mechanis1ns ................................. ........................ ........................... 64
`3.1 .5. Monitoring time-outs .......................................... ........................ ...................... 65
`3.1 .5.1 . One global time-out ................................ ........................ ........................... 65
`3.1.5.2. One monitoring time-out per message .... ........................ ........................... 66
`Intemal Network Management States ........................................................ 66
`3 .1 . 5. 3.
`3.1 .6. Operating Modes ...................................... ........................ ................................ 68
`3.2. Algorithins and behaviour .................................. ........................ ........................... 68
`3 .2.1 . Configuration Management ....................... ....................... ................................. 68
`3.2.1 .1 . Counter Inanageinent. ........................ ........................ ................................ 68
`3.2.2. Operating Mode ........................................ ........................ ................................ 72
`3.2.2.1. User Guide to handle BusSleep ................................ ................................. 72
`3.2.3. State Machine in SDL ............................... ........................ ................................ 74
`3.2.3.1. SDL Model for one global time-out TOB .................................................. 74
`3.2.3.2. SDL Model for one monitoring time-out per message ................................ 79
`
`4. System generation and API .............................. .................... ......................................... 86
`
`4.1 . Overview ............................................ .................... .............................................. 86
`4.2.
`Conventions for Service Description .......... .................... ....................................... 87
`4.2.1 . System Generation ................................ .................... ........................................ 87
`4.2.2. Type of Calls .................................... .................... ............................................ 88
`4.2.3. En·or Characteristics ....................................... .................... .............................. 88
`4.2.4. Stmcture of the Description ....................... .................... ................................... 88
`4.2.4.1 . System Generation Support.. .......... ..... ................ ..... ...................... ........... 89
`4.2.4.2. Se1vice Descriptions ...................... .................... ........................................ 89
`4.3. General Data. Types .................................. .................... ........................................ 90
`
`Page2
`PAGE3 OF 139
`
`### by OSEKIVDX
`
`NM Concept & API 2.51
`
`

`

`QSEKNDX
`
`NetworkManagement
`Concept and Application Programming Interface
`
`Conunon se1vices ............................. ...................................................... ................ 90
`4.4.
`4.4.1 . Standard Functionality ...................... ...................................................... ........... 90
`4.4 .1 .1 . System Generation Support .... ..... ....................... ................ ...... .................. 90
`4.4.2. Configuration Management .......... ...................................................... ................ 92
`4.4.2.1 . Data Types ........................... ...................................................... ................ 92
`4.4.2.2. System Generation Support .... ..... ................. ...... ................ ...... ................. . 92
`4.4.2.3. Se1vices ........ .................... .............................................. .................... ....... 95
`4.4.3. Operating Modes and Operating Mode Management.. ........................................ 98
`4.4.3.1 . Data Types .................... .............................................. .................... ........... 98
`4.4.3.2. System Generation Support .... ..... ................. ...... ................ ...... ................. . 99
`4.4.3.3. Se1vices ........ .................... .............................................. .................... ....... 99
`Se1vices for direct NM ................... .............................................. .................... .... 102
`4.5.
`4.5.1 . Standar d Functionality ............... .............................................. .................... .... 102
`4. 5 .1 .1 . System Generation Support.. ....... ..... ............... ..... ............... ..... ............... . 102
`4.5.2. Operating Modes and Operating Mode Management.. ...................................... 103
`4.5.2.1 . Se1vices ........ .................... .............................................. .................... ..... 103
`4.5.3. Data Field Management ......... .............................................. .................... ........ 104
`4.5.3.1 . Data Types .................... .............................................. .................... ......... 104
`4.5.3.2. System Generation Support.. ....... ..... .................... ............... ..... ................ 104
`4.5.3.3. Se1vices ........ .................... .............................................. .................... ..... 105
`Se1vices for indirect NM ................ .............................................. .................... .... 106
`4.6.
`4.6.1 . Standard functionality ................ .............................................. ................... ..... 106
`4. 6 .1 .1 . System Generation Support ...................................................................... 106
`4.6.2. Configuration Mangement. ........... ...................................................... .............. 107
`4.6.2.1 . System Generation Support.. ............ .................... .................... ................ 1 07
`
`5.
`
`I1npacts to OS and to COM ................... .............................................. .................... .... 107
`
`EITorCodes .................... .................... .............................................. ................... 107
`5.1 .
`Conunon iinpacts .. .................... .............................................. .................... ......... 108
`5.2.
`5.2.1. Requii·ements to OSEK C01mnunication (OSEK COM) ................................... 1 08
`5.2.2. Requii·ements to OSEK Operating System (OSEK OS) ................ .................... 11 0
`Impacts fi:om dii'ect NM ..................... .............................................. ................... 111
`5.3.
`5.3.1. Inte1face to OSEK Conununication (OSEK-COM) .......... ................................ 111
`Impacts fi:om indii·ect NM ................... .............................................. ................... 113
`5. 4.
`5.4.1. Inte1face to OSEK Conununication (OSEK-COM) .......... ................................ 113
`5.4.1 .1 . Mapping Nodeid, Netld ~Sender ............................................ .............. 114
`
`6. Histo1y ............................ ........................ ...................................................... .............. 115
`
`7. Annex ..................................................... ...................................................... .............. 115
`
`IIDplementation proposal ( dii·ect NM) ..................................... ................. ............ 115
`7 .1 .
`7 .1 .1 . Ove1view oflntemal Activities .. ......................................... ................. ............. 116
`7.1 .2. Specification oflntemal Activities ...................................................... .............. 118
`7.1 .3. NMPDU .............. ........................ ...................................................... .............. 123
`7.1 .3.1 . OpCode ............................... ...................................................... .............. 124
`7 .1 .3 .2. Encoding and decoding .......... ...................................................... ............ 125
`
`NM Concept & API 2.51
`PAGE40F 139
`
`### by OSEKIVDX
`
`Page 3
`
`

`

`QSEKNDX
`
`Netw orkManagement
`Concept and Application Programming Interface
`
`Addressing Mechanisms .................................................................. 125
`7.1 .3.2.1.
`Coherent Allocation ofNM message Headers ................................. 126
`7.1.3.2.2.
`Non-coherent Allocation ofNM message Headers .......................... 128
`7.1.3.2.3.
`Node Identifications ........................................................................ 128
`7.1 .3.2.4.
`7.1 .4. Scalability ........................................................................................................ 128
`Implementation proposal (indirect NM) ............................................................... 130
`7 .2.
`7.2.1. Scalability ........................................................................................................ 130
`7.2.2. IInple1nentation hints ........................................................................................ 131
`7.2.2.1. Choice one global time-out I one monitoring time-out per message .......... l31
`7.2 .2.2. Configuration of extended states detection algorithm ................................ 131
`7.2.3. Summa1y ofSDL state diagram graphical notation ........................................... l33
`7.3. Outlook ............................................................................................................... 134
`
`8.
`
`Index ............................................................................................................................ 135
`
`Introduction
`
`There is an increasing tendency for electronic control units (ECUs) made by different
`manufacturers to be networked within vehicles by serial data c01mnunication links.
`Therefore, standardisation of basic and non-c01npetitive in:fi·astmcture in ECUs aims at
`avoiding the design ofunnecessruy vru·iants and saving development time.
`In the scope of the OSEKNDX co-operation, the Network Management system (NM)
`provides standardised features which ensure the functionality of inter-networking by
`standru·dised interfaces.
`
`The essential task ofNM is to ensure the safety and the reliability of a c01mnunication network
`for ECUs.
`
`In a vehicle a networked ECU is expected to provide ce1tain features:
`
`### each node must be accessible for authoiised entities
`
`### maximum tolerance with regard to te1nporruy failures
`
`### supp01t of network related diagnostic features.
`
`At a basic configuration stage, NM implementations complying with OSEK specifications must
`be ilnplemented in all networked nodes. This ilnplies a solution for NM which can be
`implemented throughout the broad range of available hardware offered in to day's ECUs.
`Therefore, the status of the network must be recorded and evaluated unifonnly at all ECUs at
`intervals. Thus each node features a detennined behaviour as regards the network and the
`application concemed.
`
`OSEK-NM offers two altemative mechanisms for network monitoring
`
`###
`
`indirect monitoring by monitored application messages, and
`
`### direct monitoring by dedicated NM communication using token principle.
`
`Page4
`PAGE50F 139
`
`### by OSEKIVDX
`
`NM Concept & API 2.51
`
`

`

`OSEK/VDX
`
`I
`
`NetworkManagement
`Concept and Application Programming Interface
`
`However, the use of these mechanisms is up to the system responsible. Processing of
`info1mation collected by these mechanisms must be in accordance to requirements as regards
`the entire networked system.
`
`System status
`
`In view of the application, NM comprises two standardised interfaces:
`
`### Software:
`
`Application program ### NM
`
`### Network behaviour:
`
`Station ### Communication medium
`
`The resulting entire system is open. Thus, it can adapt to new requirements within the
`restrictions defined by the system design.
`
`Remarks by the authors
`
`This document descdbes the concept and the API of a network management, which can be
`used for ECUs in vehicles. It is not a product description which relates to a specific
`implementation.
`
`General conventions, explanations of te1ms and abbreviations have been compiled in the
`additional inter project "OSEK Overall Glossary".
`
`Summary
`
`In order to achieve the essential task of a network monitoring, i.e.
`
`### ensure safety and reliability of a communication network for ECU s,
`
`OSEK-NM describes node-related (local) and network-related (global) management methods.
`The global NM component is optional. However, it requires a minimum local component to be
`operational.
`
`Therefore, the following services ru·e provided:
`
`### Initialisation ofECU resources, e.g. network inte1face.
`
`### Strut-up of network
`
`### Providing network configuration
`
`### Management of different mechanisms for node monitoring
`
`### Detecting, processing and signalling of operating states for network and node
`
`### Reading and setting of network- and node-specific pru·ameters
`
`### Co-ordination of global operation modes (e.g. network wide sleep mode)
`
`NM Concept & API 2.51
`PAGE60F139
`
`### by OSEKIVDX
`
`Page 5
`
`

`

`QSEKNDX
`
`Netw orkManagement
`Concept and Application Programming Interface
`
`### Support of diagnosis
`
`There are two main pa1ts within the document: Direct Netl·vork Management described by
`Chapter 2 and Indirect Netlvork Management described by Chapter 3. Both chapters describe
`the concepts, the algorithms and behaviour.
`
`The Subsections Concept describe the fimdamental aspects of the configuration management,
`the operating states and operating state management.
`
`The Subsections Algorithms and Behaviour describe the protocol used for communication
`between nodes.
`
`Chapter 4 describes the Application Programming Interface comprising the pure specification
`of the setvices offered by NM for both direct and indirect. Input and output data, the
`functional description, patticularities, etc. are described for each setvice. Fmthennore System
`Generation services are described within this chapter.
`
`Chapter 5 describes Impacts on OSEK Infrastructure and gives a brief description of all
`requirements to OSEK Collllllunication and OSEK Operating System for both direct and
`indirect NM.
`
`1. Scope of the OSEK Network Management
`
`Embedding of the Network Management
`
`OSEK NM defines a set of services for node monitoring. The next figure shows how the NM
`is embedded into a system. It is also shown that the NM has to be adapted to specific
`requirements of the bus system used or to the resources of the nodes.
`
`Page6
`PAGE 7 0 F 139
`
`### by OSEKIVDX
`
`NM Concept & API 2.51
`
`

`

`OSEK/VDX
`
`Network Management
`Concept and Application Programming Interface
`
`Operating System
`
`Application
`
`u
`
`Interaction Layer
`
`Communication
`11 Ill
`I
`
`Ill
`
`5)
`
`Station
`Management
`
`1..111 1)
`
`.....
`~ ......
`
`Network
`Management
`
`4 )
`
`.....
`....
`
`6)
`OSEK
`Algorithms
`
`1---
`
`.....
`......
`
`7)
`
`Protocol
`specific
`Algorithms
`
`u
`Network Layer
`
`Data Link Layer
`2)
`
`3)
`
`Ill
`Ill
`
`n
`;
`1 Protocol Circuit r Protocol Circuit f
`1 1nterface Circuit H Interface Circuit
`. . .
`
`~,
`
`Network 1
`
`~,
`
`Network k
`
`Figure 1
`
`inte1face and algodthms responsibility
`1) API, fixed by OSEK
`2) several busses collllected to one !lController
`3) interface to DLL- COM specific, protocol specific
`4) interface to COM Interaction Layer
`5) station management (outside OSEK, see text below)
`
`6) OSEK algorithms
`7) protocol specific management algorithms
`
`OSEK NM
`
`interface to interact with the application (API)
`
`algorithm for node monitoring
`
`OSEK intemal interfaces (NM <-> COM, ... )
`
`algorithm for transition into sleep mode
`
`NM protocol data unit (NMPDU)
`
`adaptation to bus protocol specific requirements
`
`CAN, VAN, Jl 850, K-BUS, D2B, ...
`
`enor handling, e.g. bus-off handling in a CAN, transmission line enor handling
`
`NM Concept & API 2.51
`PAGE80F 139
`
`### by OSEKIVDX
`
`Page 7
`
`

`

`QSEKNDX
`
`NetworkManagement
`Concept and Application Programming Interface
`
`interpretation of the status infonnation, e.g. oven1lll or enor active/passive in a
`CAN
`
`adaptation to node resources
`
`scaling of the NM as a requirement of the node
`
`application specific usage of the NM se1vices
`
`adaptation to hardware specific requirements
`
`adaptation to a protocol circuit and a physical layer circuit
`e.g. switching the bus hardware to one of the possible physically power save
`modes
`
`station management (system specific algolithms)
`
`There are a variety of additional tasks to co-ordinate a network. Those are not described
`by OSEK, since they are system dependent. Hence these tasks are done by the
`application, e.g. by a module called station management.
`
`Philosophy of Node Monitoling
`
`Node Monitoring is used to inf01m the application about the nodes on the network. Thus the
`application can check with the appropliate service if all stations required for operation are
`present on the network.
`
`2. Direct Network Management
`
`2.1. Concept
`
`2.1.1. Node Monitoring
`
`OSEK-NM supp01ts the direct node monitoring by dedicated NM communication. A node is a
`logical whole to which a c01mnunication access is possible. A micro processor with two
`c01mnunication modules connected to two different communication media (e.g. low speed
`CAN and a high speed CAN) represents two nodes fi:om the OSEK point of view.
`
`The rate of the NM communication is controlled across the network (minimisation ofbus load
`and consumption of resources) and the messages are synchronised (avoiding negative effects
`on application data by message bursts).
`
`Eve1y node is actively monitored by eve1y other node in the network. For this purpose the
`monitored node sends a NM message according to a dedicated and unif01m algorithm.
`
`Page 8
`PAGE9 OF 139
`
`### by OSEKIVDX
`
`NM Concept & API 2.51
`
`

`

`OSEKNDX
`
`Network Management
`Concept and Application Programming Interface
`
`Direct node monitoring requires a network-wide synchronisation of NM messages. For this
`purpose a logical ring is used.
`
`Logical ring
`
`In a logical ring the communication sequence is defined independent fi:om the network
`stmcture. Therefore each node is assigned a logical successor. The logically first node is the
`successor of the logically last node in the ring.
`
`Thus the decentralised control of the overall amount of NM messages is ensured and the bus
`load due to these messages is dete1mined. The communication sequence of the logical ring
`synchronises NM communication. Any node must be able to send NM messages to all other
`nodes and receive messages fi:om them.
`
`node
`
`Electronic Communication Unit
`
`-- - ----B...,A - --- - -
`' .
`A->~
`' '
`
`\.-----'·c--~,·---~f
`'
`I
`
`' ' I
`
`I
`I
`
`-- - --- B ~A. - -- - - -- ...
`
`c ..., s
`
`I
`
`I
`
`' '
`
`I
`I
`
`communication
`media 1
`
`communication
`media2
`
`Figure 2
`
`Infrastmcture of the NM (logical ring), example with two busses
`
`Princip le
`
`The direct NM translnits and receives two types of messages to build the logical ring. An alive
`message introduces a new translnitter to the logical ring. A ring message is responsible for the
`synchronised nmning of the logical ring. It will be passed fi:om one node to another (successor)
`node.
`
`Receive alive message
`
`Receive ring message
`
`Time-out on ring message
`
`State of a node
`
`Interpretation as translnitter related registration to the
`logical ring.
`Interpretation as translnitter specific alive signal and
`synchronisation to initiate translnission of own NM
`message according to the logical ring algorithm.
`Interpretation as trans1nitter specific break down
`
`A monitoring node is able to distinguish 2 states of a monitored node.
`
`node present
`
`~ specific NM message received (alive or ring)
`
`NM Concept & API 2. 51
`PAGE 10 OF 139
`
`### by OSEKIVDX
`
`Page9
`
`

`

`QSEK/VD X
`
`Network Management
`Concept and Application Programming Interface
`
`node absent
`
`~ specific NM message not received during time-out
`
`A monitoring node is able to distinguish 2 states of itself
`
`present or not mute
`
`~ specific NM message transmitted (alive or ring)
`
`absent or mute
`
`~ specific NM message not transmitted during time-out
`
`2.1.2. Addressing
`
`The status of nodes and of the network has to be acquired and evaluated unifomlly at intervals.
`For this purpose, all nodes must communicate via their NM.
`
`The NM communication is independent of the underlying bus protocol. Each node can
`c01mnunicate unidirectional and address related with any other node of the network. Therefore
`individual and group addressing of nodes is required.
`
`Node addressing
`
`Address related communication has to take into account receiver and emitter. Each node has a
`mlique identification which is known in the network.
`
`Each address related communication message contains certain data, the emitter identification
`and the receiver identification. OSEK NM does not specify the encoding of these components
`into selected bus protocols.
`
`Emitter
`(source)
`
`Receiver
`(destination)
`
`Data
`
`address related message
`
`I Header
`
`I
`
`I
`
`Data
`
`I] general protocol format
`
`Figure 3
`
`Exemplruy representation of encoding of a NM c01mnunication message
`onto a general protocol f01mat.
`
`Individual addressing is implemented by node addressing using 1 : 1 connections. Group
`addressing is implemented by node addressing using 1 :k connections (k < number of nodes in
`the network). For this purpose groups of receivers join group addresses.
`
`Page 10
`PAGE 11 OF 139
`
`### by OSEKIVDX
`
`NM Concept & API 2.51
`
`

`

`OSEK/VDX
`
`I
`
`Features of node addressing
`
`NetworkManagement
`Concept and Application Programming Interface
`
`### Each node is assigned a unique identification known within the whole network.
`
`### Emitter and receiver identifications are explicitly included in the message.
`
`### 1 :k connections are implemented using group addresses.
`
`### all messages are broadcasted
`
`### Integrating a new node in an existing network does not require notification of the
`existing nodes.
`
`2.1.3. NM Infrastructure for Data Exchange
`
`The NM supports the transfer of application data via its infrastmcture (the logical ring).
`During the time delay between the reception and the transmission of the ring message the
`application is able to modify the data.
`
`The possibility is given to the application to specify and implement management algorithms
`which are not provided by OSEK.
`
`logical predecessor
`
`Station
`
`\ t=O
`' ~
`t=T ( delay
`
`~J>J:>Iication!
`
`...
`.... Data
`-> ind
`->Read
`Buffer <-Transmit
`
`NMmessagereceived
`I Data
`I
`I
`
`I
`
`•
`
`I Data
`I
`NM message to transmit
`
`I
`
`I
`
`I
`
`logical successor
`
`Figure 4
`
`Mechanism to transfer application data via the logical ring
`
`2.1.4. 2.1.4.Standard Functionality
`
`### Initialisations are perf01med with any system start ("cold start"), e. g. timer
`services required fi:om the operating system or communication hardware via the
`data link layer interface.
`
`### Before the system is switched off - or switches off automatically - NM can be
`"shutdown", so that it can restore e.g. to the previously known network hist01y
`when the system is statted up again.
`
`NM Concept & API 2.5I
`PAGE 12 OF 139
`
`### by OSEKIVDX
`
`Page I I
`
`

`

`QSEK/VD X
`
`Netw ork Management
`Concept and Application Programming Interface
`
`### The NM handles individual parameters, e.g. time outs and node identifications and,
`ifnecessruy, version numbers to identify hardware and software versions.
`
`2.1.5. Configuration Management
`
`2.1.5.1.
`
`Network Configurations
`
`In the absence of any faults, the networked nodes are activated at different times, e. g.:
`
`Stations on temlinal30 (pe1manent power): Wakeup via extemal event
`
`Stations on te1minal l S (ignition): Switch ON via ignition key
`
`Stations with switch in supply line: switching ON and OFF at random, by dliver
`
`However, the actual configuration is also altered by faulty nodes and by defects in the
`c01mnunication network. Consequently, different actual configurations can result for the
`individual nodes in the course of time, which ru·e additionally subject to extemal influences, e.g.
`actions by the driver.
`
`As a mle, each node wants to strut its application as quickly as possible. In view ofNM, this
`means that an actual configuration is made available to the applications as soon as possible.
`Finally, it is up to the application to decide whether to strut communication ilmnediately after it
`has become operable, or whether to wait lmtil a minimum configuration is detected by NM.
`
`OSEK-NM distinguishes between
`
`### actual configuration:
`set of nodes to which access is possible
`
`###
`
`limp home configuration:
`set of nodes which due to failure cannot pruticipate in the logical ring
`
`Therefore NM provides the following ser