Let me start out with this statement: my OSEK skills are decent, but I’m not the foremost expert here. I will tell you what I know and leave it up to you to belittle me in the comment section. Thank you.
The OSEK standard is a large section of documents that cover many, many aspects of CAN BUS communication, Network Management is a small section of this entire cadre. The entire document can be purchased publicly, I just don’t remember how. The Network Management section (2.5.3; available for free download here) is 130+ pages and is a riveting tale of bits and bytes. So let me tell you about some of the highlights…
OSEK Network Management (NM) primarily works by passing a ‘token’ around a logical ‘ring’. This token is simply like passing a one byte message to your neighbor and then your neighbor passes it to his neighbor and so on until it comes back to you and you start the process all over again. The key here is what does the message token mean? At first the message token just broadcasts your network management ID. For example if your CAN BUS Arbitration ID is 0x420 your NM ID would be 0x20 (the lower byte of your Arb. ID). Each node on the bus would have its own NM message. So if you have five nodes you would have five NM messages all of them within a particular range (this range is specified by the OEM not OSEK).
Once the node has sent out its ID, it starts listening for other NM messages (it knows of other NM messages because these messages will be in a particular range of Arbitration IDs). Once a certain time has elapsed it will send a token to its neighbor. This might look like this: 0x420 21 12 00 00 00 00 00 00 00 00. Where the 0x21 is its neighbor’s ID and 0x12 is the token. Once the neighbor has received his message, he will in turn send his own NM message with his own token: 0x421 26 32 00 00 00 00 00 00. Where 0x26 is the next node ID in the ring and 0x32 is the token. And then the cycle would continue, where each node passed their token to the next node and so on.
The token is encoded data that indicates the node’s desired state for the network. For instant if the network should go to sleep, nodes that wish for sleep will turn on an “enable sleep” bit in the token. If all of the nodes enable this bit, then the final node to elect for sleep will then send the “sleep network” bit and the network will go to sleep. This sleep is only temporary until another message is sent, this will initial a network wakeup and NM messages will start broadcasting with a token that indicates this message is an Initialization message.
So the key to a NM message is how the token is decoded and this is not specified by the OSEK layer but rather by the OEMs themselves.
