GUARDS applications are VxWorks and QNX. Both operating systems claim compliance to. POSIX 1003.1b (the real-time extensions). As some of the POSIX ...
TIME-RELATED DEPENDABILITY MECHANISMS IN GUARDS Ljerka Beus-Dukic, Andy Wellings Department of Computer Science, University of York York, YO10 5DD, United Kingdom Phone: (44) 1904 432735, Fax: (44) 1904 432767 E-mail: ljerka{andy}@cs.york.ac.uk
Abstract Dependability mechanisms in GUARDS are supported by a set of specific software and hardware components and design rules for their development and implementation. In this paper we focus on the time-related dependability mechanisms: computational and scheduling models, and spatial and temporal firewalls. An operating system provides the run-time support that is generic to all applications conforming to GUARDS computational and scheduling model. The two operating systems chosen for GUARDS applications are commercial operating systems. However, they do not provide all the necessary services needed for the implementation of the time-related mechanisms. An additional set of GUARDS services is introduced to implement pre-emptive priority scheduling.
1. Introduction
architectures developed for safety-critical realtime applications, and cheaper commercial architectures for open software intensive applications. Additionally, a set of methods, techniques and tools for the support of the design, implementation and validation of the specific instances of the architecture has been devised and is being deployed in the project. The project (more details in (Rabejac and Schindler 1997)) is currently in its development and experimentation phase. This means that the design choices are made and the implementation of the GUARDS hardware and software components is underway.
2. Architecture The GUARDS generic architecture is defined (Powell 1997) along three axes: 1.
The GUARDS1 project is an ESPRIT project with the aim to design and develop a Generic Upgradable Architecture for Real-time Dependable Systems. Instances of this generic architecture should result in a class of architectures that falls between costly proprietary
2.
1
3.
GUARDS is partially financed by the European Commission as ESPRIT project 20716. A consortium of European partners consists of three end-user companies: Technicatome (France), Ansaldo Segnalamento Ferroviario (Italy) and Matra Marconi Space France; two technologyprovider companies: Intecs Sistemi (Italy), Siemens AG Österreich PSA (Austria); and three academic partners: LAAS-CNRS (France), Pisa Dependable Computing Centre (Italy) and the University of York (United Kingdom). See http://www.cs.york.ac.uk/~ljerka/guards.html for more details on the project.
Channel axis gives the primary fault containment region; the instances of the architecture can be configured with 1 to 4 channels. Multiplicity or intra-channel axis provides the means to have a secondary fault containment region and/or to improve the performance as channel can have several independent processor boards. Integrity axis protects critical components from the propagation of faults from lesscritical components; it is implemented through spatial and temporal isolation and an appropriate integrity policy.
The GUARDS architecture favours the use of commercial off-the-shelf (COTS) components. This stems from the project’s fundamental objective to develop a generic architecture for the range of critical real-time applications. Hardware and software components can then be used as building blocks for any specific instance
1
of such architecture. However, during the study phase of the project the project consortium have realised that some hardware and software components of the architecture had to be purpose-designed and built. These specific GUARDS components implement the dependability mechanisms.
3. Time-related dependability mechanisms A GUARDS mechanism is composed of GUARDS components and design rules for the development and implementation of the mechanism (Schindler 1997). It provides a mean to apply a given dependability on a GUARDS instance. GUARDS mechanisms are mainly used to support inter and intra-channel processing (e.g. clock synchronisation, data consolidation). Here we describe the time-related mechanisms: computational and scheduling models (used at both inter-channel and intra-channel level) and firewalling which is a part of multi-level integrity mechanism (used only at intra-channel level).
and the high priority thread is executed. The lower priority thread executes again when it is the highest priority runnable thread. Time triggered computational model is appropriate for the application consisting of a fixed set of periodic functions. For the time triggered computational model, each periodic function is represented as a thread; threads are allocated a priority, usually according to the deadline monotonic priority ordering, and are pre-emptively scheduled. This means that whenever a thread becomes runnable, which is of a higher priority than the currently running thread, the currently running thread is preempted immediately. The high priority thread is then executed. Timing analysis is required to ensure that all threads meet their deadlines. If the application functions are solely sporadic in nature and the response times are such that preemption is needed, then an event triggered computational model with the pre-emptive priority scheduling model is appropriate. In this approach, each application function is represented as a thread which waits for the event to occur using some form of synchronization agent. Interrupts are viewed as an event releasing a sporadic thread.
3.1 Computational/scheduling model A computational model defines the form of concurrency supported by GUARDS (for example, processes, threads, asynchronous communication, etc.) and any restriction that must be placed on application programs to facilitate their timing analysis (for example, bounded recursion). A computational model consists of the mechanism which releases the executable function (periodic and sporadic) and the mechanism with which functions synchronise and communicate (synchronous and asynchronous). Three computational models are defined for GUARDS (Wellings, Beus-Dukic et al. 1996): time triggered, event triggered and mixed (time and event triggered). A scheduling model dictates the way in which the functions of an application conforming to a particular computational model are executed at run-time. The scheduling model chosen for GUARDS applications is pre-emptive priority. Pre-emptive scheduling has the property that if a high priority thread becomes runnable and a lower priority thread is currently executing, the lower priority thread is stopped from executing
Clearly, the most flexible approach is to have a mixed computational model. Mixed computational model consists of periodic and sporadic functions which communicate asynchronously via shared memory. 3.2 Firewalling GUARDS applications include processes of different criticality. In order to ensure that different application processes do not interfere with each other, in particular, that low-level criticality processes cannot interfere with highlevel criticality processes, the spatial and temporal firewalling mechanisms are used. Spatial firewalls are needed to protect the application’s address space. This kind of protection is usually achieved with memory management hardware and software. Temporal firewalls are necessary to police the execution time of each thread. The processes can be isolated by spatial and temporal firewalls but they also have to be able
2
POSIX functionality
GUARDS
Microkernels
Prioritybased preemptive
VxWorks
QNX
pthreads
4
6 (task)
6
fork
4
6
4
semaphores
4
4
4
mutexes and condition variables
4
6(mutex semaphore)
6
message passing
4
4
4
signals
4
4
4
timers
4
4
4
asynchronous I/O
4
4
6
priority scheduling
4
4
4
shared memory objects
4
4(not POSIX)
4
memory locking
4
4
6
Table 1: GUARDS profile functionality for different microkernels
to communicate at different levels. However, the technology information flow between processes on different levels of criticality needs to be closely monitored and appropriate checks carried out in order to prevent low-level processes hogging resources needed by high-level processes. In addition to spatial and temporal firewalls, an adequate integrity level management for GUARDS applications have to be in place, to ensure that there is no violation of integrity between different levels (Totel, Deswarte et al. 1998).
system(s). The two operating systems chosen for GUARDS applications are VxWorks and QNX. Both operating systems claim compliance to POSIX 1003.1b (the real-time extensions). As some of the POSIX functionality is missing from both operating systems (Beus-Dukic and Wellings 1997), for the implementation of the time-related mechanisms we have adopted a pragmatic approach to use a POSIX function if it is implemented otherwise use equivalent proprietary function. 4.1 Computational/scheduling model
4. Operating system services To comply with the basic GUARDS aims of genericity and upgradability, the basic operating system services for real-time scheduling and firewalling are being developed using a serverbased operating systems based on microkernel. A microkernel provides the run-time support system which is generic to all applications conforming to a particular computational and scheduling model. Hence the decision to select commercial POSIX compliant2 operating 2
The operating system should ideally be compliant to POSIX 1003.1 (the basic operating system interface
The POSIX functions (see Table 1) support GUARDS computational and scheduling models as they provide the functionality needed for periodic and sporadic threads, communication and synchronisation between processes, and preemptive priority based scheduling.
(IEEE 1990)) 1003.1b (the real-time extensions (IEEE 1993)) and 1003.1c (the threads extensions (IEEE 1995)).
3
4.2 Firewalling In multi-threaded applications memory management hardware and software must support separate virtual address spaces for each application. All the threads of an application must reside in its own virtual address space; when a thread is scheduled, the appropriate memory management registers must be set up to support the application’s address space. POSIX provides suitable mechanisms for spatial firewalls in the form of process abstractions. However, VxWorks does not support a process. Furthermore, MMU hardware and software is optional in VxWorks. In QNX the microkernel fully utilizes the MMU to deliver the POSIX multi-process model.
scheduler which pre-empts a low priority thread by a high priority one. In the time triggered computational model, temporal firewalls between different threads require the use of budget timers. In the event triggered computational model, the microkernel must maintain a sporadic thread’s invocation rate to ensure the temporal firewalls between the threads. A CPU budget timer is set to the amount of CPU time required by a thread for each invocation. Whenever the thread is pre-empted, the timer is stopped, only to be restarted next time it executes. As currently POSIX does not support CPU budget timers an alternative mechanism needs to be implemented. Deadline overrun can be detected by a watchdog timer.
5. GUARDS services
Temporal firewalling requires: 1. 2. 3.
All periodic activities to run at the assigned rate. All sporadic activities to run with the assigned frequency. All WCETs to be adhered to.
A limited form of temporal firewalling is automatically provided by the pre-emptive
A number of GUARDS services will be common to all GUARDS application processes. GUARDS services will be implemented in a layer of software which lies between the microkernel and the GUARDS application. To implement GUARDS’s pre-emptive priority scheduling, both time and event-triggered, we need three services:
#include void suspendPeriod(periodic_task_data *periodic_task) { siginfo_t info;
/* signal information */
/* turn on watchdog timer */ periodic_task->watchdog.it_value = periodic_task->period; timer_settime(periodic_task->watchdog_timer,TIMER_ABSTIME,&periodic_task>watchdog, NULL); sigaction(&periodic_task->deadline_sig.sigev_signo, &periodic_task->sa, NULL); sigwaitinfo(&periodic_task->set, &info); return;
/* wait for the signal */
/* go back to the calling periodic task */
} Figure 1. GUARDS service suspendPeriod() - VxWorks implementation
4
1.
Suspend until next period (suspendPeriod())
2.
Suspend until next event (suspendEvent()); this GUARDS service suspends the sporadic until an event and then waits on a timer until its minimal inter-arrival time has passed.
3.
Signal event (sendEvent()); this service is used by a periodic or sporadic which releases a sporadic.
The services suspendPeriod() and suspendEvent() need to be initialised first. This is achieved with two additional GUARDS services initSuspendPeriod() and initSuspendEvent(). The implementation of suspendPeriod() GUARDS service in VxWorks (details shown in Figure 1) is straightforward since all the POSIX functions needed are available. Since VxWorks does not support POSIX pthreads mutexes and condition variables, the VxWorks implementation of the suspendEvent() GUARDS service (see Figure 2) has to employ semaphores to achieve mutual exclusion and condition synchronisation.
#include #include #include #include /* VxWorks library */ void suspendEvent(sporadic_task_data *sporadic_task) { struct timespec siginfo_t
first;
info;
semTake(sporadic_task->sem_mutex);
/* lock mutex */
while(!sporadic_task->e_arrived) { /* look for event */ semGive(sporadic_task->sem_mutex); /*unlock mutex */ /* block the task until the condition*/ sem_wait(&sporadic_task->sem_condition); semTake(sporadic_task->sem_mutex); } sporadic_task->e_arrived = 0; /* calculate next invocation time */ clock_gettime(CLOCK_REALTIME, &first); if (timespec_greater_than(first,sporadic_task->start_time)) { first = timespec_plus(first, sporadic_task->MAT); } else { first = timespec_plus(sporadic_task->start_time,sporadic_task- >MAT); } semGive(sporadic_task->sem_mutex); timer_settime(sporadic_task->sporadic_timer, 0, &sporadic_task>required, &sporadic_task->old); sigwaitinfo(&sporadic_task->set, &info); return;
/* go back to the calling sporadic task */
} Figure 2. GUARDS service suspendEvent() - VxWorks implementation
5
6. Conclusion We presented the design choices made for the development of time-related dependability mechanisms in the GUARDS project. As GUARDS industrial partners have already began the implementation of the GUARDS mechanisms we expect a further evaluation and refinement of these components. The mechanisms will be tested on three different prototypes representing the diverse real-time application domains: nuclear submarine, railway and space systems.
Totel, E., Y. Deswarte, et al. (1998). Implementing Safety Critical Systems with Multiple Levels of Integrity. Data Systems in Aerospace '98, Athens, Greece. Wellings, A. J., L. Beus-Dukic, et al. (1996). Computational Models and Time-Related Dependability Mechanisms for GUARDS. Department of Computer Science, University of York, UK. GUARDS D1A4/AO/7012/B.
7. References Beus-Dukic, L. and A. J. Wellings (1997). TimeRelated Dependability Mechanisms and GUARDS Run-Time Components. Department of Computer Science, University of York, UK. GUARDS I1SA2/AO/7040/A. IEEE (1990). Portable Operating System Interface: Part 1: System Application Program Interface (API) [C Language]. IEEE. Std 1003.11990. IEEE (1993). Portable Operating System Interface: Amendment 1: Realtime Extension [C Language]. IEEE. Std 1003.1b-1993. IEEE (1995). Portable Operating System Interface: Amendment 2: Threads Extension [C Language]. IEEE. Std 1003.1c-1995. Powell, D. (1997). Preliminary Definition of the GUARDS Architecture. Laboratoire D'Analyse et D'Architecture des Systemes, France. LAAS Report 96277, GUARDS D1A1/AO/5000/D. Rabejac, C. and H. Schindler (1997). GUARDS Generic Upgradable Architecture for Real-Time Dependable Systems. Data Systems in Aerospace '97, Seville, Spain. Schindler, H. (1997). Specification and Preliminary Design of Dependability Mechanisms. Matra Marconi Space France. GUARDS D100/TO/2007/C.
6
