Introduction
Periodic messages are currently used on all automotive bus networks to ensure the receiving nodes will get the current value of the signals concerned even if there are intermittent problems with the network.
Service Oriented Architectures (SOA) on the other hand provide services which are invoked when required and typically form either a publish-subscribe or client-server pattern.
Periodic CAN messages
Periodic CAN messages are transmitted from one transmitter to one or more receivers of the message, these messages are typically transmitted periodically, whether the data has changed since the previous transmission or not. The messages normally include more than one signal packed into the available 8 bytes of a CAN message.
Periodic messages are used to ensure receiver(s) will receive the message concerned, the message transmitter will transmit the messages whether or not all the receivers are in a state to receive the message, so to ensure all receivers eventually receive the signals concerned the messages are transmitted periodically. Only one message is used to transmit the message to many receivers, so it is impractical for the receivers to acknowledge receipt of the message, because if there was an acknowledgement the transmitter wouldn’t know which receiver was sending the acknowledgement and how many acknowledgements would be required to ensure the message reached all receivers.
Service Oriented Architecture based messages
Service Oriented Architecture (SOA) messages are created as a service contract between 2 applications, where each application is aware of the state of the other application and an SOA Quality of Service (QoS) can be used to determine the status of the contract.
Publish-Subscribe SOA pattern
SOA publish-subscribe pattern the publisher explicitly publishes signals to each subscriber, the publisher can publish signals to more than one subscriber, but each publish-subscribe contract is explicitly with each subscriber. Publish-subscriber pattern is used to exchange data or events from a publisher to one or more subscribers. The data/events are published by calling a function in the publisher and received using a function callback in the subscriber(s), so the subscribers explicitly know when the data has been updated.
Depending on the QoS requirements it is possible for a subscriber to acknowledge receipt of the published information, so if the publisher does not receive an acknowledgement for one of the subscribers it is possible to republish the data to the subscriber(s) concerned.
Furthermore, the publisher of the signal subscribes to the lifecycle services of the signal’s subscribers, so it is aware of the status of the subscribers, and if one of the subscribers is currently not available the signal will not be published to the subscriber until the subscriber becomes live whereupon the publisher can publish all the required signals to the recently instantiated subscriber.
Client-Server SOA pattern
SOA client-server pattern enables a client to utilise a service when required. Client-server pattern is used to request the service to perform an action, more than one client can request the action from the service provider concerned. The service provider may or may not accept the service request and can provide feedback by returning arguments from the service.
The client(s) can invoke a service using either of the following techniques:
Synchronous or blocking - the software function calling the service waits with a timeout for the reply from the server, this mechanism is not recommended since it can add significant delays in operation.
Asynchronous, non-blocking - the software call to the service returns straight away and a callback is called when the service action has completed together with any returned arguments.
Fire-and-forget - the software call to the service returns straight away and the client does not bother to check the return arguments from the service.
Reliability Quality of Service
The Quality of Service (QoS) for a CAN base messaging system is level 0 - delivered with best effort, at most once, aka fire and forget, which results in no confirmation. Adding a higher QoS to a CAN based network would be expensive and complicated because CAN messages are broadcast to all (potential) subscribers, and the publisher of the message would need to know who the subscribers are to ensure all the acknowledgements have been received. Therefore to improve robustness of CAN based network messages, most messages are transmitted periodically even though the signals have not been updated between messages. This makes poor use of the available bandwidth; if a message hasn’t changed and it has been received by all subscribers there is no need to send it again.
The reliability QoS attribute for Publish-Subscribe can be configured to either
Best effort, fire and forget, comparable to CAN based messaging with no confirmation
Guaranteed reception, where a message will be published to each subscriber, and if any of the subscribers fail to send an acknowledge within a timeout the message will be retransmitted to the failed subscriber(s) until all the acknowledgements have been received.
The subscriber can be configured to guarantee order of reception by including the publisher’s timestamp, and the subscriber keeps track of the latest timestamp for each message, an older message would be discarded, or an error could be logged.
Periodic messages compared to Publish-Subscribe
The main difference between periodic update of data and publish-subscribe is that with periodic update the data is transmitted even if the data has not changed, whereas publish-subscribe the data is transmitted when requested by the publisher, usually when there has been a change in value. Using publish-subscribe it is possible to specify a guaranteed reliability QoS, this will cause the publisher to republish the message if a message is not received by a subscriber, the publisher effectively transfers the data periodically until the subscriber acknowledges receipt whereupon the publisher will transmit the data only when it changes.
There is a subtle difference though between periodic message update and guaranteed reception reliability QoS, in that with periodic update the receiver continuously receives confirmation that the value has not changed and the receiver can read the update bit to determine that the value has been updated. If the update bit is not acted upon then there is no qualitative difference between periodic messages and publish-subscribe with a guaranteed reliability QoS.
The functionality of the update bit can be replicated identically using publish-subscribe if the publisher publishes the data periodically, in which case the reliability QoS can be set to best effort, but this will have the overhead of publishing the same data to the subscriber repetitively. Alternatively, the functionality of the update bit can be emulated using publish-subscribe with a guaranteed reliability QoS and the subscriber monitoring the lifecycle state of the publisher, this will ensure the subscriber knows the publisher is “alive” and connected, so there cannot be any missing published data.
Periodic messages compared to Client-Server messaging
Periodic messages can be used by a transmitter to request actions on the receiver, e.g. remote control message to central door locking can be set to lock or unlock; instrument pack message centre can monitor the status of systems to determine which messages to display. In both these examples the onus is on the receiver to detect the conditions in which to perform the action; this is always the case in a message based system, even if there is a dedicated message for the action. The receiver needs to repeatedly poll the message and include some logic to determine the action. Whereas with a SOA based client-server messaging the server (receiver) does not need to do anything until a specific service request function is called, the calling of the function triggers the action explicitly with any appropriate arguments; there is no client specific logic in the server to determine what the action should be and any required data is transferred with the arguments.
Separation of concerns and decoupling
From a purely architectural perspective, the SOA design approach tends to improve the separation of concern and reduce the coupling between the client and server, so the server does not need to have any knowledge of the client implementational details (how a message is encoded).
In a message based system the message normally contains information relating to the transmitter (client) which the receiver (server) needs to interpret specifically for the message concerned, and different messages from different transmitters need to be interpreted using message specific algorithms or logic, so the receiver will include some coding specified by the design of transmitter because of the information in the message.
Network bandwidth usage
Periodic messages use a fixed quantity of the network bandwidth all the time the system is active irrespective of whether an action is required, whereas an SOA client-server message will only be transmitted when the client detects that the server’s action is necessary. Frequently these service requests could be very infrequent, most of the messages to the instrument pack messaging system will not be displayed for most vehicle journeys.
CPU execution
Periodic messages need to be regularly polled and values compared to determine whether an action is required, this will require constant CPU execution, whereas in SOA client-server, the server only executes when it has been “called” by the client.
Examples
Central locking example
One of the projects I worked at Jaguar and Land Rover explored architectural methods to improve the central locking feature used in their cars. The original central door locking system included 5 sources of locking control (clients), remote control blip, master switch, crash unlock, auto re-locking and drive away locking. Over the years this has been increased to 12 sources of locking control, each requiring an input and modification to the logic in the central locking controller. Each of the inputs (22 in total) are polled every time the central door locking system executes to determine if an action is required. Most of the messages from the clients are transmitted periodically on the CAN bus and will also contain “no action”.
If the original central door locking system had been developed using a client-server SOA pattern there would have been 1 lock request and 1 unlock request for the 5 clients which would support the interface requirements for the modern system with 12 clients, resulting in less significant modifications to the central locking system (minor configuration modifications would probably be required). The server based lock and unlock requests do not use any CPU cycles when there is no action required, which is much more efficient use of the controller. Messages from the clients will only be transmitted when the required action is requested using less network bandwidth, furthermore the clients can receive an acknowledgement of the action request allowing a retry if necessary.
Instrument pack messaging centre example
There are approaching 500 instrument pack messages that can be displayed by the instrument pack messaging centre, for each of these messages the instrument pack checks the values of signals sent periodically on the vehicle CAN bus(s). Many of these signals are transmitter specific status information which needs to be interpreted in a specific way to determine if a driver message needs to be displayed, resulting in up to 500 tests on the message centre related signals to determine which messages to display. The logic for the interpretation of the signals is design related to the transmitter of the signals and is not related to the functionality of the instrument pack messaging centre.
Whenever a system requires a new message to be created, the instrument pack will need to be modified to include the signal carrying the information and logic included to evaluate the signal and display the relevant message. Most of the signals are status information which the instrument pack does not require except to determine what message to display, and most of the time the signal comparison will result in no messages or no change to the current message.
Using a client-server SOA based pattern would result in a few server based requests to display a message and the status signal tests would be pushed back to the clients which simply call the relevant display message request with a specific message id to indicate which message to display. The instrument pack messaging centre would be responsible for displaying messages and not interpreting status information to determine which message to display. The message centre would not need to receive the status signals previously used to determine which messages to display. Whenever a system requires a new message the message centre interface would not need to be changed, but the new message would need to be added to the available messages, resulting in significantly less maintenance effort and opportunity for errors (in defining and interpreting specifications for which signals to subscribe to, test and what the status values represent) on the instrument pack messaging centre.
