Can Kingdom and Reliable Systems
In this article, you can read about the High Level Protocol - Can Kingdom , which in turn lies on top of ISO 11898 CAN . The article will consist of two parts:
1. Can Kingdom and reliable systems (general concepts, examples)
2. Assembled system with Can Kingdom. A kingdom without a king.
A lot can be found about CAN Open materials in any language, this is due to the widespread use of this protocol, but CAN Kingdom is simpler at some points (both in implementation and in understanding). In this article I wanted to share with you as well as general information about CAN Kingdom (I did not find anything in Russian on the Internet), as well as an example of the system I collected based on it.
ISO 11898 CAN is a low-level protocol. Any system requires a high level protocol that will make it as reliable as possible. Of course, the reliability of the system depends on the devices it contains, as well as on the situations arising from it. For example, the hydraulic oil of the sawmill overheats. If it moves on a flat hard surface, the obvious solution to the problem is simply to stop, but if the car drives over marshy ground, then stopping will cause it to start sucking into the ground. Or another example, a plane can safely turn off engines if it is on the ground, but not in the air. It is obvious that you can easily bring many more examples, such as propellers, processes, automated production, etc., all these systems are suitable for using the CAN protocol, but have very specific limitations and requirements for a high-level protocol. CAN Kingdom is designed to solve this problem, giving the system developer the opportunity to optimize the high-level protocol of his system, while still using the standard product.
')
Four fundamental fundamentals of CAN Kingdom:
The separation between the module and the system level is the key to system reliability. Separation can be made based on the fact that any relationships in the system are predetermined. Relationship determination is the heart of the system. Any module that interacts with another does this according to a well-thought-out set of rules developed by a system developer.
CAN Kingdom allows you to do this using the "building blocks" that are in each module. This system architecture gives me the opportunity to rule anytime, even during direct work. This is reminiscent of an ancient kingdom: the King makes laws for his kingdom, and the Mayors of each of the cities monitor their local implementation. Mayors are solely responsible to the king, who controls their loyalty. The king may change laws from time to time to maintain the stability and effectiveness of the kingdom during times of crisis. This is CAN Kingdom, the strongest tool in the hands of a system developer.
To avoid ambiguity, CAN Kingdom uses specific semantics, which will be outlined below.
How to organize and manage a reliable system is highly dependent on the system itself and on its structure. The structure of the system, in turn, depends on the state of the various modules at the current time. A reliable system must always be safe, but in most cases it is impossible to have an absolutely safe system while it is working. An airplane can be considered safe when standing on the runway, without crew, and with systems turned off. But every step on the road to takeoff increases the risk. Security and opportunity are conflicting requirements and the final system must be a compromise between them. It is therefore very important to distinguish between the responsibility of the system and the responsibility of the module. In CAN Kingdom, the developer of the module is focused on solving local problems and on the opportunity to provide a choice when a controversial situation occurs. The system developer must organize the system and make this choice.
The basic architecture of the CAN Kingdom system is one watch module, the Capital, with the watch program, the King. This is the property of the system developer, the Founder of the Kingdom. He is solely responsible for the behavior of the system. The developer of the module, the founder of the city, is solely responsible for its module, the City, and for the program of this city, Mera. The King and each Mayor has a library of common procedures, royal documents with which the king can distribute governing messages, and documents of the mayor with which the mayor can respond. A simple system is depicted in Figure 1.
There are four main nodes, the Capital with the King, 2 sensor nodes, City 1 and City 2, and the last node, City 3, using information from the sensors. Programs (nodes) are divided into parts. Each node has at least 3 parts, the Royal documents and documents of the Mayor, for managing the system, and the third part for the main program. CAN message records are located in separate folders, providing the ability to control data flow at the system level.
We summarize: there is the Capital in which the program is located which controls the system - the King , the King controls the Cities (modules), through the programs written for this - Mayors . CAN messages are stored in special folders . Which can be divided into 3 parts: Royal, Mayors and Specials. Folders are created by the founder of the city (the developer of the module). Envelope - CAN message. Page - a special byte, which allows you to understand exactly which Royal or Mayor document came.
The royal documents are a set of control messages each, of which configures the module for work in the system. They all have one CAN Id, default 00h. The first data byte in the message is the address of one of the system elements, or a group of elements. Address 00h is transmitted to all nodes. The next byte is the page number to identify the various commands.
Form royal page x:
Document Name: Royal Document
Document list: 0.1 Capital / .0 City
Document number: 0 Capital / 0 City
Document Type: Transfer (Capital)
Receiving (City)
Description of the page.
Page number:
Number of lines: 8
Description of data:
Description of lines.
Line 0: City or group address
Line 1: xxxxxxxxx (Page x)
Line 2: rrrrrrrr Commands
Line 3: rrrrrrrr
Line 4: rrrrrrrr
Line 5: rrrrrrrr
Line 6: rrrrrrrr
Line 7: rrrrrrrr
The royal document is a set of messages, transmitted by the king, and messages received by the Mayor. Each Mayor has one message to send as an answer. The CAN Id for this message is the node number plus the “base number”, which is assigned by the King in time for the boot sequence.
Form of Mayor's Page 0:
Document Name: Mayor Document
Document list: 0.1
Document number: 1.1
Document Type: Transfer
Description of the page.
Page Number: 0
Number of lines: 8
Data Description: Identification of the city, EAN-13 code
Description of lines.
Line 0: RRRRRRRR reserved R = 0
Line 1: xxxxxxxxx (Page x)
Line 2: rrrrrrrr Reply
Line 3: rrrrrrrr
Line 4: rrrrrrrr
Line 5: rrrrrrrr
Line 6: rrrrrrrr
Line 7: rrrrrrrr
The founder of the Kingdom (System Developer) can only be responsible for his system if he has approved all Cities. No other modules should be connected. There are 2 ways to check members: by polling their IDs, and by monitoring the bus traffic. Each City in CAN Kingdom has a unique EAN or UPC number. It tells the manufacturer, product number and serial number of the City.
When the Mayor receives the Royal Page, he will, as soon as possible, respond with the requested Page from his (Mayor's) documents. Page 0 contains the EAN / UPC code, Page 1 - the serial number. I will not paint the pages themselves; they can be found in the documentation.
The King, using Page 1, requests from the Mayor Document Page 0 as an answer, each City must respond with its EAN / UPC code. Taking the Base number from each Envelope (message), the King receives the address of each City and from the received Page the product number. Then he can verify the correctness of the association of the address and the equipment. A new request for Page 1 of the Mayor will give the King a serial number, and after saving it, he will be able to track any replacements of the Cities, as well as download specific system settings as needed.
The basic access control to the CAN bus is bitwise arbitrage. Even if CAN Kingdom supports time scheduling and garland access, bit-wise arbitration is justified by the basic mode, allowing fast unplanned alarms and using as a backup mode if the schedule or chain has collapsed. The reliability of the CAN system largely depends on the correctness of the priority of each individual message. The system developer has a complete understanding of the entire system as a whole and is responsible for setting priorities. In the CAN Kingdom system, each City has only one CAN Id initially, the Envelope to receive the Letter of the King. He receives a transferred Envelope, for the Mayor's Page on the first Royal Page (setting of the base and physical number), and for all the others on the second Royal Page (number of envelopes).
To control access to the bus in the system of reaction to events, it is not enough to have only the correct message priorities. It is also necessary to associate the maximum repetition period of messages.
We will not go into details about the time at CanKingdom, but it is worth noting that the King can set the maximum re-send time for each Envelope. This does not solve the problem of "muttering idiot", but allows you to calculate the maximum delay time and properly configure any message.
Purely event-based communication or communication based on local non-synchronized clocks will lead from time to time to situations in which messages will be lost at 100% bus load. One way to find out if Cities are alive is a message-garland. One message will cause another to be sent. This behavior is configured by the Royal Page 5 page. With this page, the King orders the Mayor to allow the Page from one Document to respond to another Page of another Document. This technique can be used not only in scheduling messages, but also to confirm applications, trigger events at other Nodes, and so on. The function can be controlled by turning on / off the Folder and the link can be removed by removing the Document from the actual Folder.
You can often hear that CAN cannot be used for a reliable system built on event processing. This is not entirely true. Standard 11898 only defines the behavior of the CAN controller. Bitwise checking solves bus collisions (bus collisions collisions or bus problems) at a predictable time. Nothing forbids anyone to use CAN in time planning systems. CAN provides the ability to create a single synchronized clock in the Kingdom, and send messages according to the time schedule. This topic is not discussed here, and you can read more about it in the CAN Kingdom specification, which can be downloaded from the official site .
For the safe operation of the Postal system (communication system) in the Kingdom
It is important that any city act in a consonant and safe way when it is connected to the Postal System.
The city can break the link in two most likely ways:
1. Using a different transmission speed, different from the speed of the Postal System;
2. Transmission of Letters (CAN Messages) in the Envelope (CAN Id) intended for transfer to another City.
In order to avoid similar incidents, the City must remain silent until the Postman (CAN controller) receives a valid Letter. If the Mayor knows the Kingdom Base Number, he announces his presence, otherwise he will wait until the King polls him.
The following launch procedure is described for CAN Kingdom Cities:
1. The mayor performs internal tests.
2. The Mayor sets the transmission rate of the Mail system to 125 kbps, and the “Silence” mode (without confirmations and without error messages) at 200 ms and waits for a Standard Letter with an envelope 2031Std containing a Page in which all 8 Lines contain AAhex.
2a. If such a letter is received within 200 ms, the Mayor saves to the register settings and switches to the “Only Listen” mode, waiting for the Royal Letter.
2b. If such a letter is NOT received during this period, the Mayor sets up the Post Office in the settings of the registers according to the intended Kingdom and place, keeping the “silence” mode and waiting for the correct letter.
When the Letter is received correctly:
3a. If the Base Number is known, the Mayor sets the Post Office to the “Communication” Mode and sends his Letter with page 0
2b. If the Base Number is NOT known, the Mayor switches to the Listen Only mode and waits for a letter from the King.
After successfully setting up the base and physical numbers, the system developer must set up Envelopes, linking the folders between cities. In fact, every folder in the city is its interface. For example, the switch on the wall has 1 interface - toggle Light. And the PLC will have more than 10 of them. The system developer must specify that, say, Interface Switch No. 1 should receive messages from Interface No. 10 of the PLC. The rest of the messages The switch should filter and ignore. This is how the system is configured in Can Kingdom using the 2nd royal page.
In addition, do not forget about the priority of messages. It depends on CAN Id, i.e. The situation might look like this:
Device #A, TX (transmit) Folder X - assigned to id N
Device #B, RX (recieve) Folder Y - assigned to id N and id M
Device #C, TX (transmit) Folder Z - assigned to id M
at the same time N <M, then if Device A and Device C simultaneously send their envelopes, then Device #B will first receive an Envelope from A and then from C.
There is one more important aspect. TX Folder can only have 1 Can ID. RX Folder in turn may have several.
System Developer (King) actually designates who will hear whom. And what device interfaces (Cities) will work in the system, receive and send messages.
With page 0, the King informs the Mayors that the settings have been completed and that they should transport the respective cities to work. It can also be used to freeze the work of a City or a group of Cities in operation mode, stop sending any letters, reloads, etc. Thus, the King is not only the activity of each city, but also their connections. Sometimes it is important during extreme conditions. Parts of the Kingdom should be disconnected from the bus, but still remain active, freeing the channel for other parts. When a city is frozen, the Mayor must be able to handle all types of Royal Letters. A city can have more than one “Freeze”, “Work”, or “Reboot” mode, which can be selected using Page 0. The King can send this message either to one City or to the Cities group, or to all Cities.
Be that as it may, Page 0 is the King’s main tool in the administration of the Kingdom in the Operating Mode, he is free to use other Pages. Cities can be added or deleted during operation, depending on how the System Developer has given them similar behavior. If the Base Number is known a priori, the Mayor will report about himself as soon as he sees a valid message on the bus, otherwise he (the number) will be appointed by the King. Accordingly, the King can decide when and how the City will be added to the Kingdom.
CAN Kingdom is designed to create stable and reliable systems based on the CAN protocol. By separating the system and module, the System Developer can fully control and be responsible for the final system. The system can be reconfigured with control messages. This feature can be used not only for the elegant degradation of the system in case of failures, but also for the modernization of the system at the development stage or after the “birth”. Common problems of various systems, such as membership agreement, bus control and operation mode monitoring can be solved using CAN Kingdom.
1. Can Kingdom and reliable systems (general concepts, examples)
2. Assembled system with Can Kingdom. A kingdom without a king.
A lot can be found about CAN Open materials in any language, this is due to the widespread use of this protocol, but CAN Kingdom is simpler at some points (both in implementation and in understanding). In this article I wanted to share with you as well as general information about CAN Kingdom (I did not find anything in Russian on the Internet), as well as an example of the system I collected based on it.
Part 1
Introduction
ISO 11898 CAN is a low-level protocol. Any system requires a high level protocol that will make it as reliable as possible. Of course, the reliability of the system depends on the devices it contains, as well as on the situations arising from it. For example, the hydraulic oil of the sawmill overheats. If it moves on a flat hard surface, the obvious solution to the problem is simply to stop, but if the car drives over marshy ground, then stopping will cause it to start sucking into the ground. Or another example, a plane can safely turn off engines if it is on the ground, but not in the air. It is obvious that you can easily bring many more examples, such as propellers, processes, automated production, etc., all these systems are suitable for using the CAN protocol, but have very specific limitations and requirements for a high-level protocol. CAN Kingdom is designed to solve this problem, giving the system developer the opportunity to optimize the high-level protocol of his system, while still using the standard product.
')
Four fundamental fundamentals of CAN Kingdom:
- Clear separation between module and system level
- Any relationships in the system are predefined.
- Provision of “building blocks” for customization of high level protocol
- Postpone the decision as far as possible
The separation between the module and the system level is the key to system reliability. Separation can be made based on the fact that any relationships in the system are predetermined. Relationship determination is the heart of the system. Any module that interacts with another does this according to a well-thought-out set of rules developed by a system developer.
CAN Kingdom allows you to do this using the "building blocks" that are in each module. This system architecture gives me the opportunity to rule anytime, even during direct work. This is reminiscent of an ancient kingdom: the King makes laws for his kingdom, and the Mayors of each of the cities monitor their local implementation. Mayors are solely responsible to the king, who controls their loyalty. The king may change laws from time to time to maintain the stability and effectiveness of the kingdom during times of crisis. This is CAN Kingdom, the strongest tool in the hands of a system developer.
To avoid ambiguity, CAN Kingdom uses specific semantics, which will be outlined below.
System and modules
How to organize and manage a reliable system is highly dependent on the system itself and on its structure. The structure of the system, in turn, depends on the state of the various modules at the current time. A reliable system must always be safe, but in most cases it is impossible to have an absolutely safe system while it is working. An airplane can be considered safe when standing on the runway, without crew, and with systems turned off. But every step on the road to takeoff increases the risk. Security and opportunity are conflicting requirements and the final system must be a compromise between them. It is therefore very important to distinguish between the responsibility of the system and the responsibility of the module. In CAN Kingdom, the developer of the module is focused on solving local problems and on the opportunity to provide a choice when a controversial situation occurs. The system developer must organize the system and make this choice.
The basic architecture of the CAN Kingdom system is one watch module, the Capital, with the watch program, the King. This is the property of the system developer, the Founder of the Kingdom. He is solely responsible for the behavior of the system. The developer of the module, the founder of the city, is solely responsible for its module, the City, and for the program of this city, Mera. The King and each Mayor has a library of common procedures, royal documents with which the king can distribute governing messages, and documents of the mayor with which the mayor can respond. A simple system is depicted in Figure 1.
There are four main nodes, the Capital with the King, 2 sensor nodes, City 1 and City 2, and the last node, City 3, using information from the sensors. Programs (nodes) are divided into parts. Each node has at least 3 parts, the Royal documents and documents of the Mayor, for managing the system, and the third part for the main program. CAN message records are located in separate folders, providing the ability to control data flow at the system level.
We summarize: there is the Capital in which the program is located which controls the system - the King , the King controls the Cities (modules), through the programs written for this - Mayors . CAN messages are stored in special folders . Which can be divided into 3 parts: Royal, Mayors and Specials. Folders are created by the founder of the city (the developer of the module). Envelope - CAN message. Page - a special byte, which allows you to understand exactly which Royal or Mayor document came.
Control messages
The royal documents are a set of control messages each, of which configures the module for work in the system. They all have one CAN Id, default 00h. The first data byte in the message is the address of one of the system elements, or a group of elements. Address 00h is transmitted to all nodes. The next byte is the page number to identify the various commands.
Form royal page x:
Document Name: Royal Document
Document list: 0.1 Capital / .0 City
Document number: 0 Capital / 0 City
Document Type: Transfer (Capital)
Receiving (City)
Description of the page.
Page number:
Number of lines: 8
Description of data:
Description of lines.
Line 0: City or group address
Line 1: xxxxxxxxx (Page x)
Line 2: rrrrrrrr Commands
Line 3: rrrrrrrr
Line 4: rrrrrrrr
Line 5: rrrrrrrr
Line 6: rrrrrrrr
Line 7: rrrrrrrr
The royal document is a set of messages, transmitted by the king, and messages received by the Mayor. Each Mayor has one message to send as an answer. The CAN Id for this message is the node number plus the “base number”, which is assigned by the King in time for the boot sequence.
Form of Mayor's Page 0:
Document Name: Mayor Document
Document list: 0.1
Document number: 1.1
Document Type: Transfer
Description of the page.
Page Number: 0
Number of lines: 8
Data Description: Identification of the city, EAN-13 code
Description of lines.
Line 0: RRRRRRRR reserved R = 0
Line 1: xxxxxxxxx (Page x)
Line 2: rrrrrrrr Reply
Line 3: rrrrrrrr
Line 4: rrrrrrrr
Line 5: rrrrrrrr
Line 6: rrrrrrrr
Line 7: rrrrrrrr
Membership Agreement
The founder of the Kingdom (System Developer) can only be responsible for his system if he has approved all Cities. No other modules should be connected. There are 2 ways to check members: by polling their IDs, and by monitoring the bus traffic. Each City in CAN Kingdom has a unique EAN or UPC number. It tells the manufacturer, product number and serial number of the City.
When the Mayor receives the Royal Page, he will, as soon as possible, respond with the requested Page from his (Mayor's) documents. Page 0 contains the EAN / UPC code, Page 1 - the serial number. I will not paint the pages themselves; they can be found in the documentation.
The King, using Page 1, requests from the Mayor Document Page 0 as an answer, each City must respond with its EAN / UPC code. Taking the Base number from each Envelope (message), the King receives the address of each City and from the received Page the product number. Then he can verify the correctness of the association of the address and the equipment. A new request for Page 1 of the Mayor will give the King a serial number, and after saving it, he will be able to track any replacements of the Cities, as well as download specific system settings as needed.
Bus Access Control
The basic access control to the CAN bus is bitwise arbitrage. Even if CAN Kingdom supports time scheduling and garland access, bit-wise arbitration is justified by the basic mode, allowing fast unplanned alarms and using as a backup mode if the schedule or chain has collapsed. The reliability of the CAN system largely depends on the correctness of the priority of each individual message. The system developer has a complete understanding of the entire system as a whole and is responsible for setting priorities. In the CAN Kingdom system, each City has only one CAN Id initially, the Envelope to receive the Letter of the King. He receives a transferred Envelope, for the Mayor's Page on the first Royal Page (setting of the base and physical number), and for all the others on the second Royal Page (number of envelopes).
To control access to the bus in the system of reaction to events, it is not enough to have only the correct message priorities. It is also necessary to associate the maximum repetition period of messages.
We will not go into details about the time at CanKingdom, but it is worth noting that the King can set the maximum re-send time for each Envelope. This does not solve the problem of "muttering idiot", but allows you to calculate the maximum delay time and properly configure any message.
Purely event-based communication or communication based on local non-synchronized clocks will lead from time to time to situations in which messages will be lost at 100% bus load. One way to find out if Cities are alive is a message-garland. One message will cause another to be sent. This behavior is configured by the Royal Page 5 page. With this page, the King orders the Mayor to allow the Page from one Document to respond to another Page of another Document. This technique can be used not only in scheduling messages, but also to confirm applications, trigger events at other Nodes, and so on. The function can be controlled by turning on / off the Folder and the link can be removed by removing the Document from the actual Folder.
You can often hear that CAN cannot be used for a reliable system built on event processing. This is not entirely true. Standard 11898 only defines the behavior of the CAN controller. Bitwise checking solves bus collisions (bus collisions collisions or bus problems) at a predictable time. Nothing forbids anyone to use CAN in time planning systems. CAN provides the ability to create a single synchronized clock in the Kingdom, and send messages according to the time schedule. This topic is not discussed here, and you can read more about it in the CAN Kingdom specification, which can be downloaded from the official site .
Boot sequence:
For the safe operation of the Postal system (communication system) in the Kingdom
It is important that any city act in a consonant and safe way when it is connected to the Postal System.
The city can break the link in two most likely ways:
1. Using a different transmission speed, different from the speed of the Postal System;
2. Transmission of Letters (CAN Messages) in the Envelope (CAN Id) intended for transfer to another City.
In order to avoid similar incidents, the City must remain silent until the Postman (CAN controller) receives a valid Letter. If the Mayor knows the Kingdom Base Number, he announces his presence, otherwise he will wait until the King polls him.
The following launch procedure is described for CAN Kingdom Cities:
1. The mayor performs internal tests.
2. The Mayor sets the transmission rate of the Mail system to 125 kbps, and the “Silence” mode (without confirmations and without error messages) at 200 ms and waits for a Standard Letter with an envelope 2031Std containing a Page in which all 8 Lines contain AAhex.
2a. If such a letter is received within 200 ms, the Mayor saves to the register settings and switches to the “Only Listen” mode, waiting for the Royal Letter.
2b. If such a letter is NOT received during this period, the Mayor sets up the Post Office in the settings of the registers according to the intended Kingdom and place, keeping the “silence” mode and waiting for the correct letter.
When the Letter is received correctly:
3a. If the Base Number is known, the Mayor sets the Post Office to the “Communication” Mode and sends his Letter with page 0
2b. If the Base Number is NOT known, the Mayor switches to the Listen Only mode and waits for a letter from the King.
Envelope customization
After successfully setting up the base and physical numbers, the system developer must set up Envelopes, linking the folders between cities. In fact, every folder in the city is its interface. For example, the switch on the wall has 1 interface - toggle Light. And the PLC will have more than 10 of them. The system developer must specify that, say, Interface Switch No. 1 should receive messages from Interface No. 10 of the PLC. The rest of the messages The switch should filter and ignore. This is how the system is configured in Can Kingdom using the 2nd royal page.
In addition, do not forget about the priority of messages. It depends on CAN Id, i.e. The situation might look like this:
Device #A, TX (transmit) Folder X - assigned to id N
Device #B, RX (recieve) Folder Y - assigned to id N and id M
Device #C, TX (transmit) Folder Z - assigned to id M
at the same time N <M, then if Device A and Device C simultaneously send their envelopes, then Device #B will first receive an Envelope from A and then from C.
There is one more important aspect. TX Folder can only have 1 Can ID. RX Folder in turn may have several.
System Developer (King) actually designates who will hear whom. And what device interfaces (Cities) will work in the system, receive and send messages.
Control during operation
With page 0, the King informs the Mayors that the settings have been completed and that they should transport the respective cities to work. It can also be used to freeze the work of a City or a group of Cities in operation mode, stop sending any letters, reloads, etc. Thus, the King is not only the activity of each city, but also their connections. Sometimes it is important during extreme conditions. Parts of the Kingdom should be disconnected from the bus, but still remain active, freeing the channel for other parts. When a city is frozen, the Mayor must be able to handle all types of Royal Letters. A city can have more than one “Freeze”, “Work”, or “Reboot” mode, which can be selected using Page 0. The King can send this message either to one City or to the Cities group, or to all Cities.
Be that as it may, Page 0 is the King’s main tool in the administration of the Kingdom in the Operating Mode, he is free to use other Pages. Cities can be added or deleted during operation, depending on how the System Developer has given them similar behavior. If the Base Number is known a priori, the Mayor will report about himself as soon as he sees a valid message on the bus, otherwise he (the number) will be appointed by the King. Accordingly, the King can decide when and how the City will be added to the Kingdom.
findings
CAN Kingdom is designed to create stable and reliable systems based on the CAN protocol. By separating the system and module, the System Developer can fully control and be responsible for the final system. The system can be reconfigured with control messages. This feature can be used not only for the elegant degradation of the system in case of failures, but also for the modernization of the system at the development stage or after the “birth”. Common problems of various systems, such as membership agreement, bus control and operation mode monitoring can be solved using CAN Kingdom.
Source: https://habr.com/ru/post/275895/
All Articles