The BIDS Software Framework

The BIDS Software FrameworkLeo Ordinez1 , Rodrigo Santos1 , David Donari1 , Javier Orozco1

1Instituto de Investigaciones en Ingeniería EléctricaUniversidad Nacional del Sur - CONICET

Av. Alem 1253 - (8000) Bahía Blanca - Buenos Aires - Argentina

{lordinez,ierms,ddonari,jorozco}@uns.edu.ar

Abstract. In this paper a software framework based on the scheduling conceptof BIDS is presented. The main objective of the proposal is to show the static anddynamic aspects of a software framework to implement BIDS. An applicationexample is also presented.

1. MotivationThe growth and expansion to new requirements on real-time systems (RTS) have deter-mined that research focuses on mechanisms capable of coping with those requirements.These kind of systems are often composed of tasks whose Quality of Service (QoS) char-acteristics are diverse and even stochastic. In this situation, tasks may interfere on eachothers performance if the scheduling mechanism does not provide a way of isolate them(regarding to temporal aspects).

The Behavioral Importance Dual-Priority Server (BIDS) scheduling algorithm[Ordinez et al. 2008] aims at providing temporal isolation among tasks and a schedul-ing method based on the last instance execution of them to adjust the QoS of the wholesystem. This mechanism postpones the execution of the next instance of a task whose pre-vious one was considered as not important, leaving that time to attend other tasks markedas important ones. The consequence of this is twofold: first, there is a flexible adaptationof the bandwidth required by a BIDS according to the task previous behavior; and second,the system keeps on working correctly because important tasks are guaranteed to execute.

Software modeling, specially for RTS, is becoming a very important disci-pline due to the growing complexity of these systems and the short time-to-market[Kopetz 2000]. Software modeling offers designers a good way to test, visualize, re-design and communicate different alternatives before implementing the complete sys-tem [Cernosek and Naiburg 2004]. In this sense, a software framework provides a usefulmechanism to attend those requirements by giving an abstract design and implementationfor an application in a given problem domain [Fayad and Schmidt 1997]. The aim of thispaper is to propose a software framework based on the scheduling concept of BIDS.

1.1. BIDS Main Features

The BIDS model presented in [Ordinez et al. 2008] states several characteristics that canbe summarized as follows: 1) tasks are independent, periodic and preemptible; 2) eachtask consists of a terminating loop; 3) reactivation of tasks is carried on by the kernel orthe BIDS; 4) each soft task, after finishing its execution, obtains an integer value basedon its information processing behavior; 5) there is a threshold established on the rangeof values returned by each task. The following aspects are related to servers: 6) each

10th Brazilian Workshop on Real-Time and Embedded Systems 85

server can encapsulate several tasks; 7) each server maintains two queues of tasks: onefor IMPORTANT and one for NOT IMPORTANT, the assignment is done dynamicallybased on the parameter returned by the task and the threshold; 8) a server behaves like avirtual processor with a speed slower than the real one; 9) a server is scheduled (along withothers hard tasks in the system) by an Earliest Deadline First (EDF) scheduler; 10) withina server tasks are scheduled in First In, First Out (FIFO) order; 11) on budget exhaustiona server can be or cannot be delayed by a time longer than its period accordingly to itspending tasks.

1.2. Specific Contribution

This paper is framed in the FLEMI [Ordinez et al. 2007] project and provides BIDS[Ordinez et al. 2008] with a software framework modelled in UML, named BIDS-SF. TheBIDS-SF facilitates the design and implementation of BIDS under a generic real-time op-erating system for embedded systems, e.g. Asterix [Thane et al. 2001]. It is worth men-tioning, that despite using the Unified Modeling Language (UML) [uml 2008] to describethe framework, it is not restricted to object-oriented methodologies for an implementa-tion. Moreover, a UML design can be easily translated to a procedural language like C byfollowing just a couple of conventions [Richardson 2007].

After this introduction, the rest of the paper is organized as follows: in Section 2previous works in the same field are revised; Section 3 shows the BIDS-SF in its static anddynamic aspects; an application note that exemplifies the functioning of the framework ispresented in Section 4; finally, in Section 5 conclusions are drawn.

2. Related WorkIn [Pautet and Tardieu 2000], [Caspersen 1999], [Isovic et al. 2000],[Hsiung et al. 2004], [Selic 2000], [Cortellessa and Gentile 2004] and[Pettit IV and Gomaa 2007] different kinds of software frameworks were presented.They differ from the BIDS-SF in several aspects among which highlights: a restrictionto a particular language, a higher level of abstraction, i.e., they center on integration ofcomponents, a different application domain and a focus on performance modeling. WhileBIDS-SF offers a generic software architecture to implement a RTS according to BIDS.Thus, BIDS-SF represents a step forward in approaching real-time scheduling theorywith implementation aspects.

3. Building the BIDS Software FrameworkIn this section, a generic base model of a RTS based on BIDS concepts will be presentedand explained. As was mentioned before, we will use UML to static and dynamicallydescribe the different parts of the BIDS-SF.

In order to introduce the general functioning of the complete system, a simplifiedmodel of it, based on the framework proposed in [Selic 2000], is depicted in Figure 1.There is one shared resource, the processor, which is managed by the kernel. Servers andhard tasks require that resource and establish a QoS contract to use it 1. Unlike the schemeproposed in [Selic 2000], the resource manager and the resource broker are the sameentity: the kernel. And in the same way, the resource management and resource allocation

1In a simplified manner the contract only determines the deadline, but it can include more constraints.

86 10th Brazilian Workshop on Real-Time and Embedded Systems

policies are put together in one scheduling policy. The kernel allocates processor to hardtasks and servers according to its QoS contract. Concerning soft tasks, the scheme issimilar to the previous one, except that the manager is the server which encapsulates them.Finally, as explained in the cited article different QoS contracts can be implemented bymeans of attributes and operations.

Figure 1. A generic QoS contract model adapted to BIDS.

3.1. Structural Modeling

The architectural structure of the BIDS-SF is depicted in Figure 2. There it can be seenthat classes CHardTask and CServer inherits from a special class, CDispTask, thatextends CTask. The CDispTask class is a class used by the kernel to dispatch thenext executing task. Class CSoftTask inherits directly from CTask and is managed byclass CServer. Aggregation and composition relationships are used to model whole/partlifecycles between system entities.

It is worth mentioning that class CDispTask intends to be a class with onlyattributes and getter and setter methods. Since the kernel has to schedule a mixing of twodifferent kind of objects (servers and hard tasks), the use of a list of CDispTask objectsthat have basically both kind of properties makes easier the job of searching among severalobjects to find the appropriate one to execute.

Although it is not the purpose of this paper to go deep into the kernel implementa-tion but in how it should support BIDS, a basic sketch of a general structure, common tomost real-time kernels is also given in Figure 2. The Hardware Adaptation Layer (HAL)class, CHAL, provides an interface between the kernel and the hardware platform (namelyCHwPlatform). Concerning the hardware management provided by the kernel it isbased on services and handlers offered by the HAL.

3.2. Dynamic Modeling

The behavior of both hard and soft task is very similar, except that soft tasks have a manda-tory operation infProcessing() that obtains the value of its execution instance inorder to adjust its next instance scheduling. Figure 3(a) and 3(b) show the statechartscorresponding to the behavior of hard and soft tasks. Both statecharts are based on theAbstract Behavior Pattern [Selic 1998], but with an extension to distinguishing the situa-tion in which a task is not running because either it was preempted or it is waiting for areactivation after having executed.

Both kinds of tasks receive a different signal when they go from the OFF state tothe Running state than when they go from the Suspended state to the Running one. This is


Figure 2. Class diagram of the BIDS-SF.

because the signal InitTaskHard/Soft involves some initialization actions that thetask may have to do before running.

The BIDS, from the point of view of the kernel, is an ordinary task, then it shares astructure similar to the rest of them: it has a Running state, an OFF state and a Suspendedone, with the same meaning of those previously presented. Since the BIDS may have toreplenish its budget, the Suspended state is further split into two: a Short Waiting stateand a Long Waiting one. As will be shown in detail in the kernel statechart, once the BIDSis in the suspended state, deadline and budget are checked. This generates an exchangingof signals between the soft task and the BIDS and between the BIDS and the kernel. TheBIDS behavior is depicted in Figure 4.

On the other hand, when the BIDS is running, its behavior is very much like theone of the kernel to be explained. It first checks for deadlines missed and properly ac-knowledges tasks if they happened (in that case, tasks may trigger an error handler toperform some recovery action). Then, it checks if any task must be reactivated. Andfinally, it chooses the next task to be executed and sends the appropriate signal (whetheris the first time it executes or it was previously preempted). While there are tasks toserve and the kernel does not send the IsPreemptedServer signal, the BIDS keepson doing this job. The classification of tasks is performed by inserting the task in the cor-responding list based on its last instance value. The function addToCorrespList isthe one which calls getValue() from the task, and performs the appropriate insertion.


(a) Hard task behavior (b) Soft task behavior

Figure 3. Statecharts of hard and soft tasks.

Figure 4. Statechart of the Behavioral Importance Dual-Priority Server

The kernel behavior is shown in Figure 5. It has a housekeeping state withtwo main parts: one in which deadlines, budget exhaustions and budget replenishmentsare handled and acknowledged to the appropriate entities; and a second part, in whichscheduling and dispatching is done. The two different executing states have mostly mod-eling reasons, to make a clear distinction of the signals involved.

One key feature of the kernel statechart is the after event used as trigger of sometransitions. This clause is the one which states a time base to the system and performs aninterrupt every time slot. Then, the kernel preempts the running task and decides which isnext task to be executed, previously doing some checking as explained above. The afterevent is also used within tasks and servers just to point out the periodic reactivation ofthem. This reactivations, in fact, are transparent to the entities since they only involve aswaping between lists inside the kernel e.g., from “waiting” to “ready”.

Finally, in Figure 6(a) and 6(b) the internal functioning of the BIDS and the kernelscheduler/dispatcher are detailed.

4. Application NoteIn this section, an example is presented. The crash-avoidance sensor network that moderncars have is tackled with the BIDS-SF. In this case, the sensors periods and resultingimportance is related to the speed the car is travelling and the proximity of the obstacles


Figure 5. Statechart of a generic kernel that supports BIDS.

or other vehicles in movement. In this sense, it is very different the available time toprevent a collision against a car ahead in the road at 120 km/h than a when car is parkingat the supermarket. Although both kind of incidents may produce injuries to the driverand other people, at high speeds the danger is greater.

The distance between cars in the highway then is a very critical point in crash-avoidance technology. In the United Kingdom, for example, the distance between cars iscomputed on the basis of the worst case response time to slow down a car to a completestop. On the other hand, in Argentina the law establishes a temporal distance betweencars of 2 seconds taken from a fixed point, e.g., a light-post. As can be seen, apart fromthe method used, once the proximity threshold is crossed the system should alert withhigher priority the existence of the obstacle. In this sense the BIDS-SF provides a goodapproach to face this kind of problem.

In general, the Collision Warning System (CWS), is integrated by many sensorsand actuators. The CWS have to poll those sources of information, process them andupdate the display and sound devices for the driver and, in case of an Active CruiseControl (ACC), modify the set point. The sensors are embedded in a BIDS while actuatorsare hard tasks. Particularly, the time interval at which the sensors are polled will dependmostly on the kind of sensor, and on the previous execution behavior by incrementing ordecrementing their priority accordingly.

Let’s suppose a car travelling at 80km/h and an obstacle on the road at 200m. Theradars have a range of 120m. Since the car is 200m far, just in 3.6s the CWS will detect thepresence of the obstacle. And, in about 65m (this is around 3s) more, the task will becomeimportant and the system will start to take an action on it, i.e. decelerate. The sequence ofactions to get a complete stop would be the ones shown in Figure 7. From the thick lineon (i.e., when soft tasks become important), the system behaves repeatedly in the way itis shown (this is, ACC task periodically adjust speed, and radar1 and radar2 execute every


(a) BIDS Scheduler/Dispatcher (b) Kernel Scheduler/Dispatcher

Figure 6. Activity diagrams of BIDS and kernel internal functioning.

server period with a short wait for replenishment) until the ACC task completely stops thecar.

5. Conclusions and Future WorkThe benefits of a software framework for RTS are proven to be many. In this sense,any scheduling algorithm for RTS needs to count with an associated software frameworkthat aids its implementation. The BIDS algorithm is an interesting scheduling concept tocope with timing and behavioral requirements of a RTS. In this paper, a software frame-work, named BIDS-SF, which provides a generic architecture to implement BIDS waspresented. In addition, a generic framework for abstract resources was adapted to thisparticular application domain and the entities involved in the system were static and dy-namically modelled. Finally, an example based on an automotive system was used toshow the adaptability of BIDS-SF to a particular scenario.

The next steps are related to extending the BIDS algorithm to consider synchro-nization issues and concerning BIDS-SF, to take into account those issues and give a morespecific structure of the real-time kernel and the way it handles the hardware.

References(2008). Unified modeling language. Website. http:\\www.uml.org.Caspersen, M. E. (1999). A c++ framework for active objects in embedded real-time systems-bridging the

gap between modeling and implementation. In Proceedings of the 32nd International Conference onTechnology of Object-Oriented Languages, Washington, DC, USA. IEEE Computer Society.

Cernosek, G. and Naiburg, E. (2004). The value of modeling. Electronically. http://www.ibm.com/developerworks/rational/library/6007.html Last visited: 03/2008.

Cortellessa, V. and Gentile, M. (2004). Performance modeling and validation of a software system in art-uml-based simulative environment. In 7th IEEE ISORC. IEEE Computer Society.

Fayad, M. and Schmidt, D. C. (1997). Special issue on object-oriented application frameworks. Communi-cations of the ACM, 40(10).


Figure 7. Temporal evolution and sequence of messages exchange.

Hsiung, P.-A., Lin, S.-W., Tseng, C.-H., Lee, T.-Y., Fu, J.-M., and See, W.-B. (Oct. 2004). Vertaf: an ap-plication framework for the design and verification of embedded real-time software. IEEE Transactionson Software Engineering, 30(10).

Isovic, D., Lindgren, M., and Crnkovic, I. (2000). System development with real-time components. InProceedings of ECOOP Workshop, France.

Kopetz, H. (2000). Software engineering for real-time: a roadmap. In Proceedings of the Conference onThe Future of Software Engineering, New York, NY, USA. ACM.

Ordinez, L., Donari, D., and Orozco, J. (2007). Flemi: an approach to a new real-time framework. InProceedings of the IX Workshop de Tempo Real, WiP session, pages 103–106, Belém - Pará, Brazil.

Ordinez, L., Donari, D., Santos, R., and Orozco, J. (2008). A behavior priority driven approach for resourcereservation scheduling. In Proceedings of the 2008 ACM Symposium on Applied Computing, Fortaleza,Ceará, Brazil. ACM.

Pautet, L. and Tardieu, S. (2000). Glade: A framework for building large object-oriented real-time dis-tributed systems. In Proceedings of the 3rd IEEE ISORC, Washington, DC, USA. IEEE ComputerSociety.

Pettit IV, R. G. and Gomaa, H. (2007). Analyzing behavior of concurrent software designs for embeddedsystems. In Proceedings of the 10th IEEE ISORC. IEEE Computer Society.

Richardson, M. W. (2007). Object based development using uml and c. White paper, Telelogic. http://www.telelogic.com/download/index.cfm?id=4984 Last visited: 03/2008.

Selic, B. (1998). Using uml for modeling complex real-time systems. In Proceedings of the ACM SIGPLANWorkshop on Languages, Compilers, and Tools for Embedded Systems, London, UK. Springer-Verlag.

Selic, B. (2000). A generic framework for modeling resources with uml. IEEE Computer, 33(6).Thane, H., Pettersson, A., and Sundmark, D. (2001). The asterix realtime kernel. In Proceedings of the

13th Euromicro Conference on Real-Time Systems.


The BIDS Software Framework

Documents

Transcript of The BIDS Software Framework