The protocol stack must recover from intermittent packet loss quickly via packet retransmission or report a message failure to the application.
Rationale: The sorts of links that these networks run on have very low bandwidth compared to Ethernet, and unlike Ethernet the links are not nearly as reliable. Packets can be lost due to interference and noise as well as collisions. When these events occur, they are relatively frequent so that more bandwidth is consumed to recover from the loss using retransmission. Second, because these systems typically have real-time constraints, delivering the packet late is not desirable.
Rationale: The sorts of links that these networks run on have very low bandwidth compared to Ethernet, and unlike Ethernet the links are not nearly as reliable. Packets can be lost due to interference and noise as well as collisions. When these events occur, they are relatively frequent so that more bandwidth is consumed to recover from the loss using retransmission. Second, because these systems typically have real-time constraints, delivering the packet late is not desirable.
It must be possible to engineer the control network so that the real-time requirements of the application are met. This involves:
Designing the network to meet response time criteria by limiting the number of nodes per link, and tuning the communications so the network will not become overloaded.Specifying that a given communications transaction will either succeed or fail within a specified time, with the success or failure of that transaction known to the application.
Rationale: In a control system, a late packet would result in some node not doing its function in synchronization with the other nodes.
The protocol stack must implement all communications services that are needed by all nodes — without diminishing any of the services. Therefore, the protocol stack must be compact so that the control application also has adequate RAM. To put this requirement in perspective, currently available devices that combine a microcontroller and an IEEE 802.15.4 radio typically have 8–12kb of RAM to share between the protocol stack and the application. Most developers expect to be able to use most of this RAM for their applications.
Rationale: In the world of low-cost systems-on-a-chip (SOCs), RAM is the most precious resource. In control networking applications, it is needed for buffers, to maintain state and know when to resend a packet, to detect a duplicate packet, to put packets in correct order for delivery, etc. These draws on the memory are in direct competition with the needs of the application. Given cost pressures, the use of SOCs is a reasonable solution.
The protocol stack must be independent of the underlying MAC/PHY interface.
Rationale: There is no single solution for all communication needs among all devices. Multiple RF, power line, and a variety of wired links are needed to implement various applications. Further, transceiver design continually evolves and improves, so the protocol stack must be able to take advantage of new technologies as they become available.
Rationale: There is no single solution for all communication needs among all devices. Multiple RF, power line, and a variety of wired links are needed to implement various applications. Further, transceiver design continually evolves and improves, so the protocol stack must be able to take advantage of new technologies as they become available.
The protocol stack must scale to thousands of nodes and to multiple links of different speeds in a single logical network.
Rationale: Many building and factory systems are composed of well over 1,000 nodes that use many types of links to a high-speed backbone.
Network wide multicast, with multicast group membership, must be supported. Grouping provides that all applications do not see and consume resources for multicasts not pertaining to them, other than to discard the packet at a low layer in the stack.
Rationale: Multicast conserves bandwidth and improves response time over multiple, serial unicast messages. When closing a control loop over a network it is sometimes critical that all nodes that subscribe to a sensor value get that value very close to the same time. Applications cannot require that all the nodes in their group are on a common link because some messages, such as emergency messages, must go to most, or even all the nodes on the network. A node does not have the memory to process all multicasts just to discover which ones do not apply to it.
Confirmed, network wide multicast must be supported.
Rationale: In applications where the message must get through or a major equipment shutdown is required the sending node must be able to have confirmation that its message was received by all the members of the multicast group.
The protocol stack must support duplicate packet detection and resend the previously generated response without reprocessing or regenerating it.
Rationale: Many types of packets should be ignored. For example, let's say a utility customer on a pre-pay contract adds money to their account, and the additional credit is transferred to their meter, but the meter’s acknowledgement packet is lost. So the utility re-sends the add credit message. Correct behavior would be for the meter to only add the credit one time.
The protocol stack must support a mechanism that allows emergency messages to be routed in an expedited manner, bypassing router and node queues.
Rationale: In control networks, sometimes all nodes respond to an event (for example, an oil refinery is about to catch fire), which causes a flood of messages. Not all those messages are crucial to resolving the problem, but the messages that are must be propagated quickly across the network.
The protocol stack must ensure that packets are received in the order they are sent.
Rationale: There are many control operations that depend on a sequence to prevent damage to equipment or simply to work correctly.ger pointing that can be more painful than any acceptance test.
No comments:
Post a Comment