Checking Real-Time Properties of CAN Bus by Timed Automata Jan Krakora and Zdenek Hanzalek Czech Technical University in Prague, Faculty of Electrical Engineering Department of Control Engineering Karlovo namesti 13, Prague 2, 121 35, Czech Republic
[email protected] Abstract The article deals with verification of an application (e.g. automotive IT equipment) based on a distributed system communicating via broadcast communications - Controller Area Network (CAN). It solves the crucial problem of verification in both, the time properties and logic properties of such complex applications. This article presents an alternative approach based on model checking while using timed automata and temporal logics. 1. Introduction In the last years the in-car communications play more and more important role in automotive technology. With growing complexity of these systems, it is rather difficult to guarantee their correct behavior. Therefore it is needed to apply new techniques for their design and analysis. car environment
sensor control
Processor 1
Processor 2
Processor 3
Applications
Applications
Applications
RTOS
RTOS
RTOS
actuator control
CAN bus RTCS
Figure 1. Real time control system structure This article deals with verification of a typical automotive IT equipment based on a distributed system. Such system consists of an application SW (designed by application developer) running under real-time operating system (e.g. OSEK) and using standard broadcast communications based on the Controller Area Network (CAN). The crucial problem is to verify both, the time properties (e.g. message response time) and logic
properties (e.g. deadlock) of such complex applications. Separate parts of this problem have been already studied in various research papers. Well know Rate Monotonic Scheduling (RMS) can be used, when the application consisting of periodic processes is running on monoprocessor with priority based preemptive kernel and the processes have their deadlines at the end of their periods. Prediction of the worst-case latencies for CAN is a direct application of the scheduling theory where the common bus is considered as shared resource. In similar way, CAN operates the fixed priority scheduling algorithm and authors assume the rate monotonic priority assignment. The message worst-case response time is influenced not only by its length but also by the maximal length of one lower priority message since a high priority message cannot interrupt the message that is already transmitted. Moreover due to the priority based bus arbitration method the message worst-case response time is influenced by all higher priority messages, considering their occurrence ratio. This article presents an alternative approach based on model checking while using timed automata and temporal logics. Using this approach we model parts of the distributed system (application SW, operating system and communication bus) by automata. The automata use synchronization primitives enabling their interconnection; therefore the model complexity grows gradually. Product of these automata is
further used for checking of desired model properties. Important part of this article is CAN arbitration model composed of several timed automatons: bus automaton, transmiter automaton per each message ID. Separate application process automatons send transmition requests to CAN arbitration model and receive acknowledgement at the end of the transmition. Further we show the case study consisting of one sporadic and three periodic application processes having different timing parameters like deadline, period and message length. Verified properties are the following: Is the system deadlock free? Is there any state in which node 1 and node 2 are both in the data transmission section? etc. 2. Basic concept of CAN Up to the standard [CAN], CAN is a message oriented transmission protocol. The message response time is given not only by the message length, but also by the access to the shared communication media, since only one node can transmit at a given time. The priority at which a message is compared to another less urgent message is specified by the identifier of each message. The priorities are laid down during system design in the form of corresponding binary values and cannot be changed dynamically. The identifier with the lowest binary number has the highest priority. MAC is resolved by bit-wise arbitration on the identifiers involved by each station observing the bus level bit for bit. This happens in accordance with the "wired and" mechanism, by which the dominant state overwrites the recessive state. The transmission is denied for all nodes with recessive transmission and dominant observation. All those nodes automatically become receivers of the message with the highest priority and do not re-attempt transmission until the bus is available again. When the controllers have priority ordered queues (e.g. Intel 82527), the transmission requests are handled in the order of the importance of the messages for the system as a
whole - global priority. In the examples shown in this article we assume one message to be transmitted from each node but due to the global priority, the approach given below does not change even if several messages are transmitted from each node. 3. Bit-wise arbitration model The model of CAN arbitration designed in UPPAAL [Dav] is shown in Figure 2. The model describes MAC mechanism for one message accessing the bus. The location no_trans_needed represents a situation when the arbitration model is waiting for trans_request from the application process. The locations send_bit_to_bus, listen_bus, check_next_bit represent the arbitration process. The locations request_denied and request_success give result of the arbitration process.
no_trans_needed trans_request? i:=i+1
send_bit_to_bus
signal[i]:=id[i]*signal[i], t:=0
check_next_bit
t>=tbit, i=0, id[i]!=signal[i]
request_denied
listen_bus t=tbit, i==(nsigi-1), id[i]==signal[i]
request_success
Figure 2: Arbitration model After processing of the start of frame bit (SOF) the first bit from the arbitration filed is sent to the bus (transition send_bit_to_bus Æ listen_bus). At the same time the transmitting node senses the bus and both transmitted bit (local variable id) and sensed bit (global variable signal) are compared. If they are identical and the end of the Arbitration field (nsigi states for the length of the Arbitration field) was not reached the next bit is proceeded (check_next_bit location) when nominal bit-time elapses (deterministically given as tbit constant). If the sensed bit is not identical to the transmitted one, the transmission is denied (request_denied location). If they are identical
and the end of the Arbitration field was reached the node wins the arbitration (request_success location). The CAN Arbitration field model designed in UPPAAL [Dav] includes the information about the duration of each bit-time given by invariant t=tbit, t>=0 on outgoing transitions. 4. Transmitter model The implementation of the complete transmitter model is depicted in Figure 3. It is composed of the three sections: the arbitration section described already in Figure 2, synchronisation section ( waiting_for_free_busÆsend_bit_to_bus transition ) that is used to synchronize all transmitting nodes prior to arbitration ( this part realises broadcast communication in UPPAAL) and data transmission section given by trans_section, trans_section_finished and trans_finished locations.
and the node is waiting for free bus again (waiting_for_free_bus location). Otherwise the node's message is sent after deterministic time Cm. When the transmission is finished (trans_section_finished) the bus gets idle (bus_trans_finished channel) and the application process is informed about the end of transmission (trans_finished_ack channel). The Figure 4 depicts the physical bus model. The model is in idle location when there is no activity on the bus and it is in busy location when any node transmits. trans_vote global variable is used to detect that at least one node is willing to start the transmission. If this is the case than the global synchronization is realized via bus_broadcast_chan from the bus model. idle
trans_vote>0 bus_broadcast_chan! trans_vote:=0
bus_trans_finished? trans_finished_ack!
no_trans_needed
trans_request? trans_vote++ trans_vote++
busy waiting_for_free_bus bus_broadcast_chan? i:=0 i:=i+1
send_bit_to_bus
signal[i]:=id[i]*signal[i], t:=0
check_next_bit
t>=tbit, i=tbit, id[i]!=signal[i]
listen_bus t=tbit, i==(nsigi-1), id[i]==signal[i] t:=0
request_denied
request_success
trans_begun t = Cm
trans_section_finished
bus_trans_finished! signal[0]:=1, signal[1]:=1, signal[2]:=1 trans_finished
Figure 3. Transmiter model The principle is the following: after receiving the transmission request, the node is in the waiting state (waiting_for_free_bus) till the bus isn't free. If the bus is idle, the arbitration starts (synchronization by urgent broadcast_synch channel). If the transmission was denied (trans_denied location), the transmission request is immediately repeated
Figure 4. Bus model 5. Application process model Figure 5. shows composition of the transmitter and bus models with models of application processes. In this experiment we assume 4 nodes to be connected by CAN bus. Each node is running one application process transmitting the messages of one given identifier. The application processes 1, 2, and 3 are periodic processes transmitting messages with identifier 1, 2, and 3 respectively. The application process 4 is a sporadic process transmitting the lowest priority message with identifier 4. The periodic application process, with period Tm, is depicted in Figure 6. Afterwards each message is delayed by time between zero and Ji. Then the transmission request is done by trans_request channel. When the message is transmitted the process is informed by trans_finished_ack channel. Location no_transmission_activity represents a situation
when the process does not perform transmission, i.e. it performs for example computations.
no_trans_activity_2
t_response_time := 0 trans_finished
node 1
node 2
node 3
no_trans_activity_1
trans_request! t_response_time := 0
node 4
trans_finished_ack?
bus_broadcast_chan
transmiter bus_trans_finished
bus_broadcast_chan
bus_trans_finished
trans_finished_ack
trans_request
trans_finished_ack
trans_request
application process 4
transmiter
bus_broadcast_chan
transmiter bus_trans_finished
bus_broadcast_chan
transmiter bus_trans_finished
application process 3
trans_finished_ack
application process 2 trans_request
trans_request
trans_finished_ack
application process 1
bus
Figure 5. Model consisting of 4 nodes Urgent location init_location starts the first task period, delayed by time between zero and Tm in order to represent the phase shift of the task. no_trans_activity t_period
