iCC 2005 CAN in Automation Thread prioritization for an embedded CANopen master stack with web interface D. M. Armenis and J. S. Smith Department of Electrical Engineering and Electronics The University Of Liverpool As Tele-robotics continuously receives industrial attention, an embedded CANopen Master Stack, accessible via the Internet, is proposed. A configurable real-time operating system permits multi-threaded development whilst PLD technology ensures system evolution. The impact thread prioritization has on system performance is investigated, whilst initial design considerations are also presented. Introduction priority interrupt is used as a pulse generator. It is responsible for distributing Multi-threaded, real-time, control a pulse, with fixed width, to the stepper processes introduce synchronization motors commanding them to advance. and timing issues, unknown to many The lower priority interrupt is used to embedded applications [1,2]. The scope of transmit the EMCY PDO during an the presented work is both to identify the emergency. In the Encoder Node, the last reasons for prioritizing control over safety slave node in the system, the higher threads and to determine their minimum priority interrupt is used as the SYNCH request period during normal operation of producer for the network. The lower an embedded CANopen Stack with Web priority interrupt is used for the EMCY Interface. The results of this study provide event as in the Drive Nodes. As a result, a clear indication of the schedulability of both time depended protocols and CAN the proposed system. The determinism of bus receivers are left unsupported. While the stack can also be improved, a required the CAN bus registers can be monitored property for bridging real-time Ethernet [3] by a polling procedure, the mandatory with CAN. Initially, the Stack was Error Control Services can only be composed of two transceiver threads, realised by the CANopen Master under the three communication threads and two Node Guarding Protocol. As expected, the databases implemented in eCos [4,5]. Node Guarding event can be attained Three monitoring threads, for guarding the by a timed, interrupt-based operation. functionality of the two required Motor Nevertheless, the delay introduced by the CANopen (Drive) Slave Nodes and the pooling procedure, at the slave nodes, will optional CANopen Encoder Slave Node manifest certain jitter effects during control [6,7,8], were added to the second version. directives, which deem this approach In its current version three control threads inappropriate for the proposed system. and two user interface threads, were Consequently, the Node Guarding added as shown in figure 1. The Protocol was accommodated in the stack, developed system has been applied to an implemented under the one-thread-per- Unmanned Underwater Vehicle (UUV) [9]. slave philosophy, with a lower priority than the control threads. Explicitly in this case, Timing Issues the designer is facing periodic, hard, real time schedulability issues as a Extension of the system to accommodate consequence of delays introduced by the more slave devices, raise some very control threads duration throughout normal interesting synchronization questions. manoeuvring. It is therefore vital to identify Suppose that a network is composed of the relationship between the Guard Slave slave nodes incapable of serving more Thread Priority (GSTP) and Life Time than two interrupts levels (e.g. slave nodes Value (LTV) [8] in an attempted to based on PIC18F453 devices). In the two decouple the system control effort from the mandatory slave (Drive) nodes, the higher Node Guarding Protocol. 10-16 iCC 2005 CAN in Automation Communication Controls Web Page Web Page Start Stop Reverse Direction Thread Distance Thread Thread SDO commands PDO Commands SDO read MASTER OD Read/Write Slave OD SDO Serving PDO producer Thread Serving Thread MASTER OBJECT SDO write to MASTER OD DICTIONARY PDO variables access [1:2] SDO Slave acknowledgment PDO attributes access [1:1] Guard Slave n PDO static LIST Guard Slave 2 CAN Receive PDO consumer Serving Thread Guard Slave 1 Thread Translate RPDO Send PDO CAN Send Thread 1 CANopen Slave CANopen Slave CAN bus CANopen Slave CANopen Slave Figure 1: Run-Time Threads Leung [10] states that a decrease in the Transmit Requests to occur at random GSTP (priority) can be achieved by intervals during the Node Life Time. This increasing the LTV (deadline) under optimizes the Node Guarding time to the the notion of the deadline monotonic best functional time interval. In the scheduling scheme. As such, a following sections, two guarantees are considerable increase in the Node proposed that ensures at least one Guarding Time (period) would have been Remote Transmit Request before the able to accommodate the maximum Node Life Time expires. Both approaches system delay. Then again, a defective try to minimize the LTV until the system node must be identified instantly, in an reaches the CPU’s maximum utilization attempt to contain the problem and ensure limit. the system’s graceful degradation, this is The remainder of the paper is organized in provided by a small Node Guarding the following manner. Synchronization period. In the current stage of the Techniques for the Node Guarding UUV development, where there is no Threads are identified in the next section. Deliberative Module, the user can send This is followed by the Priority low level commands to the robot on an Assignment Calculations section where irregular basis making the whole system the schedulability of the system is tested. sporadic. Assuming a fixed time interval The methodology for the proposed tests is where at least one command will be then presented. Subsequently, in the issued, the system becomes periodic. Discussion section, the worst case results Therefore the proposed work differentiates are considered. The paper concludes by slightly from the Node Guarding Protocol highlighting the importance of this work to by permitting the Node Guarding Remote the field of UUVs. 10-17 iCC 2005 CAN in Automation Synchronization Techniques GSTP n Assuming one or more slave nodes, the developer might face the dilemma of LTV 1 GSTP 1 LTV n LTV organizing the Node Guarding Threads in one of four different ways as described in table 1. Table 1: Synchronization Methods Figure 2: Sync method I Synchronization Same Same II. In this scenario the nodes all have the Methods GSTP for LTV for same LTV but a different GSTP. This all slaves all slaves min case is illustrated in figure 3. The I difference from method I is that all II _ threads must satisfy equation (3), to III _ ensure normal operation during a delay. IV _ _ min = + − ⋅ LTV D (2n 1) Cguard (3) I. In this method, the GSTP can be Although (3) makes the system decreased by increasing the LTV independent of the time the delay occurs, individually for each node. Neither the it introduces a uniform approach for the priority nor the LTV is the same for any LTV which might not be desirable in slave as shown in figure 2. Assuming some implementations. that the constant C guard, is the time necessary for a guard slave thread to be completed. If no higher priority thread is GSTP n active this is subject only to code length and the processor speed,. It is also the GSTP 1 same for all guard slave threads. Let n n LTV LTV 1 be the number of all mandatory Node Guarding Threads during the application. The minimum period for the highest T min = n ⋅ C priority thread is guard so that Figure 3: Sync method II there is enough time for every thread to be completed before the first thread is III. In the third method all the threads have overdue. Let D be an unexpected system the same priority. Again the minimum delay (i.e. a higher priority thread = ⋅ LTV is LTVmin n Cguard but many becomes active) such that threads do accommodate larger values C < D < T min guard . Then for every thread as shown in figure 4. In an event of a p with: system delay only the threads that have ⋅ > ⋅ + < ⋅ + will fail regardless n Cguard p Cguard D (1) LTV Cguard a D where p ∈[1..n] , the minimum LTV can of the time that the delay occurred. be equal to the minimum period Tmin. Alternatively, the minimum LTV is: min = + + − ⋅ LTVp D (n p 1) Cguard (2) This equation is subject to the time the LTV n LTV 1 LTV GSTP n delay occurred. As the delay approaches GSTP 1 the lowest priority threads, the minimum LTV increases for all the system except for those threads that satisfy relationship (1). Figure 4: Sync method III 10-18 iCC 2005 CAN in Automation IV. In the last method, all the threads are will not be executed more than once sharing both the same priority and the during their deadline. same LTV as illustrated in figure 5. If the delay satisfies the relationship 3000 ⋅ < 2500 n Cguard D , all threads will fail but if ⋅ ≥ 2000 n Cguard D all threads will succeed. 1500 Time (ms) 1000 500 LTV n LTV 0 Thread 1 Thread LTV 1 LTV 5 15 25 35 45 55 65 75 85 95 Degrees to turn Figure 5: Sync method IV 5000 4000 Priority Assignment Calculations 3000 Timing trials of the control application 2000 Time (ms) determined the direction deadline on the 1000 UUV system. This is the maximum time of 0 processor usage from the higher priority 5 15 25 35 45 55 65 75 85 95 threads. It was found that 4350 ms was Degrees to turn necessary for the UUV robot to execute a turn of 45 degrees from rest. This is the Figure 6: Turn duration travelling at maximum permitted rotation angle for the full speed (top) and from rest (bottom) vehicle due to its dynamics constraints.