1

A data-centric approach to composing embedded, real-time softwarecomponents∗

Roel Wuytsa,Stephane Ducassea, Oscar Nierstrasza,

a{wuyts} {ducasse} {nierstrasz}@iam.unibe.chSoftware Composition GroupInstitut fur InformatikUniversitat Bern, Switzerland

AbstractSoftware for embedded systems must cope with a variety of stringent constraints, such as real-time requirements,

small memory footprints, and low power consumption. It is usually implemented using low-level programminglanguages, and as a result has not benefitted from component-based software development techniques. This paperdescribes a data-centric component model for embedded devices that (i) minimizes the number of concurrent tasksneeded to implement the system, (ii) allows one to verify whether components meet their deadlines by applyingRate Monotonic Analysis (RMA), and (iii) can generate and verify schedules using Constraint Logic Programming(CLP). This model forms the foundation for a suite of tools for specifying, composing, verifying and deployingembedded software components developed in the context of the PECOS project.

1. Introduction

Component-based software development(CBSD) is quickly becoming a standard ap-proach to develop mainstream software systems.Most component models and systems, such as(D)COM, .Net, JavaBeans [ 17] and CCM [ 24],however, target the development of mainstreamdesktop applications with abundant hardwareresources. None of these existing models explic-itly addresses the constraints imposed by smallembedded devices. Although CBSD would bringnumerous advantages to the embedded systemsworld, such as shorter development times, andthe ability to secure investments through reuse ofexisting components, in practice, standard com-ponent models are too heavyweight to be appliedto embedded systems development.

In this paper we outline an approach to CBSDfor embedded systems developed in the contextof the European IST project PECOS2. PECOS en-

∗In Journal of Systems and Software — Special Issue onAutomated Component-Based Software Engineering, vol.74, no. 1, 2005, pp. 25-34.2 Pervasive Component Systems, IST-1999-20398. ABB

ables CBSD for small embedded systems by pro-viding an environment that supports the specifi-cation, composition, configuration checking, anddeployment of embedded systems built from soft-ware components. The PECOS approach was ap-plied in the context of field devices, small embed-ded devices developed by the prime contractorof the project, ABB. The central element of theapproach is a data-centric component model thatmakes it possible to check non-functional require-ments of component compositions.

The PECOS component model is unusual inthat PECOS components have very simple inter-faces consisting solely of data ports. Componentsare either active, event or passive, and interactionoccurs only where data ports are connected. Thisdesign choice makes it particularly easy to reasonabout synchronization and timing aspects of com-ponents. First of all, it enables timing analysisof component compositions using rate monotonic

Corporate Research Centre, Ladenburg (DE), ResearchCentre for Information Technologies (FZI), Karlsruhe(DE), the Software Composition Group (SCG) at the Uni-versity of Bern (CH), and Object Technology International(OTI), Amstelveen (NL).

2

Figure 1. Pneumatic positioner (TZID) field de-vice.

analysis, a technique for verifying that a set oftasks can meet their deadlines. Second, it enablesschedule verification of component compositionsusing a constraint logic programming approach.

The next section describes the context of fielddevices, their specific constraints and the solu-tions proposed by the PECOS project. Then Sec-tion 3 presents the PECOS component model.Sections 4 and 5 then address the issues of thetiming verification and schedule verification ofcompositions. Section 6 discusses the model andsome related work. We conclude with a few re-marks on the current status of this work.

2. Field Devices: Context and Challenges

Rather than attempt to develop a CBSD ap-proach for the embedded systems domain in gen-eral, the PECOS project focussed on the specificchallenges and demands of field devices. In thissection we introduce field devices, consider theproblems they pose for CBSD, and outline howPECOS tackled these problems.

2.1. Field DevicesField devices are small reactive, embedded sys-

tems that make use of sensors to continuouslygather data, such as temperature, pressure or rateof flow. An example of a typical field device is theTZID pneumatic positioner (Figure 1), used tocontrol pneumatic actuators attached to valves.Such devices have the following characteristics:

• The available power is only 100 mW for thewhole device. This limits the choice of suit-

Device FQD

PA

ModBus

actualPosition

velocitytheActualPosition

theVelocity

frequencyToSetfrequencyToSet

Figure 2. A canonical field device containingthree subcomponents: Device and ModBus (ac-tive), PA (passive), and FQD (event).

able CPUs. The software architecture isdriven by the fieldbus architecture, a com-mon standard for linking devices from dif-ferent manufacturers. Fieldbus stack imple-mentations from third party suppliers areused and need to be integrated.

• Field devices use one dedicated processor,optimized for overall power consumptionwith a speed ranging from just a few MHzto several tens of MHz. The processor typi-cally has some RAM (around 20 kilobytes),non-volatile memory and a great deal of I/Oon-chip, but often lacks extra functionalitylike a floating point unit.

• Parts of the software impose real-time con-straints, such as the control loop, and theexecution of fieldbus function blocks.

• The device has a static software configura-tion, i.e., the firmware is updated or re-placed as a whole, without dynamic load-able functionality. There is also no require-ment for dynamic memory allocation.

• Many field devices are used in safety criticalareas, such as chemical plants and thereforerequire costly certification procedures. Inorder to minimize the chance of certificationfailures, thorough testing is needed.

3

2.2. A Canonical Field DeviceIn order to validate CBSD for embedded sys-

tems, the PECOS project developed both hard-ware and software for a demonstrator device withcharacteristics very similar to the TZID field de-vice. This device is concerned with setting a valveat a specific position between open and closed.Figure 2 shows a component Device containingthree connected subcomponents that collaborateto set the valve position. A control loop is usedto continuously monitor and adjust the valve.

ModBus is an active component i.e., with itsown thread of control. It is responsible for inter-facing to a piece of hardware called the frequencyconverter, which determines the speed of the mo-tor. The frequency to which the motor should beset is obtained from the PA component. ModBusoutputs this value to the frequency converter us-ing the ModBus protocol (hence its name). TheModBus component requires its own thread, be-cause it blocks waiting for a (slow) response fromthe frequency converter.

FQD (Fast Quadrature Decoder [ 18]) is anevent component that is triggered when an eventis raised from the motor. This component ab-stracts from a micro-controller module that doesFQD in hardware. It provides the PA with thevelocity and the position of the valve.

PA is a passive component that implements thecontrol loop to set the valve to a certain position.It holds the desired position of the valve, reads thecurrent state of the valve from the FQD compo-nent, computes the new frequency for the motorcontrolling the valve and passes this to the Mod-Bus component. This repeated adjustment andmonitoring constitutes the control loop.

This example is used throughout the paper toillustrate the different concepts that are intro-duced.

2.3. The PECOS ApproachPECOS develops a CBSD approach that ab-

stracts from best practice in field device softwaredevelopment. It is non-intrusive, and evolution-ary, rather than radical, and consists in the fol-lowing elements:

• Component Model : the component modelis the foundation for the tools. It abstracts

from best practice in software design forfield devices, and supports reasoning aboutnon-functional constraints (timing, schedul-ing and memory consumption).

• Component Description Language (Coco):Coco implements the PECOS componentmodel and is used to specify componentsand field devices.

• Code Generation: Coco specifications areused to generate code skeletons.

• Runtime Environment (RTE): Generatedcode targets the RTE, which abstracts fromthe real-time operating system used.

• Verification: When components are com-posed, functional and non-functional as-pects of the composition can be verified.Composition rules express constraints overcompositions, such as dependencies be-tween components. Non-functional checksinclude timing analysis, schedule genera-tion and verification, and checks on memoryconsumption.

This paper only presents the component modeland the timing verification. Detailed informationon the other items can be found in [ 7] or on thePECOS website mentioned before.

3. The PECOS Component Model

The PECOS component model has been de-signed with the particular requirements of fielddevices in mind, and reflects best practice in thisdomain. For this reason the model differs sub-stantially from typical component models, and ismuch simpler in many respects.

3.1. Design choicesThe following design choices for the PECOS

component model directly reflect best practice inthe field device domain:

• Cyclic behavior : Each component is respon-sible for a single task which is repeatedly ex-ecuted. However, the model also supportsaperiodic event or active components.

4

Propertykeyvalue

PropertyBundlename

Componentnameexecute()

Porttypedirectionrange

Connectortype

Passive Active

synchronize()

Event

synchronize()

1*1

11

1

*

*

subComponents

timingmemory

Figure 3. Overview of the PECOS ComponentModel.

• Fine-grained components: Components en-capsulate a single task and export a datainterface. They communicate by means ofshared data. The result is a fine-grainedmodel that makes it possible to minimizeconcurrency and check timing constraints.

• Threading : Components may be active, i.e.,have their own thread of control, event (tomodel the capture of an event), or passive.

• Minimize critical sections: Contention forshared resources must be minimized due tothe high cost of locking data on the plat-forms used.

• Separate scheduler : Control flow is sepa-rately specified by a scheduler for compositecomponents.

3.2. Static StructureThe PECOS field device component model [ 3]

defines a vocabulary of components, ports, con-nectors, and the rules governing their composi-tion. The model is illustrated in Figure 3.

A component is a computational element witha name, a number of property bundles and ports,

and a behavior. There are active componentswith their own thread of control, passive com-ponents without their own thread of control, andevent components, whose behavior is triggered bya hardware or software event. The behavior of acomponent consists of a procedure that reads andwrites data available at its ports, and may pro-duce effects in the physical world. This behav-ior is modeled as the entry point labelled exec.A port represents data which is read or writtenby a component, and which may be shared withother components. Each port is characterized byits name, its type, a range of possible values, anda direction (in, out or inout) indicating whetherthe component reads, writes, or reads and writesthe data.

A composite component is specified by connect-ing selected ports of its internal subcomponents(that can be composites themselves). A connec-tor describes a data-sharing relationship betweenports. It has a name, a type, and a list of portsit connects. Only compatible ports may be con-nected [ 3]. Composite components need to spec-ify a schedule for executing their subcomponents.

A property is a tagged value. The tag is anidentifier, and the value is typed. A propertybundle is a named group of properties. Propertybundles are used to characterize aspects of com-ponents, and are used to add meta-information tothe model, such as information regarding timingor memory usage.

In the example of Figure 2, FQD is an eventcomponent, PA is a passive component and Mod-Bus is an active component. The composition it-self (the Device component) is an active compos-ite component. FQD has out ports actualPositionand velocity, connected to in ports of PA (the-ActualPosition and theVelocity). The out portfrequencyToSet of PA is connected to the in portof the same name on ModBus.

3.3. Execution ModelWe now consider the dynamic aspects of the

model, in particular synchronization and schedul-ing.

5

Device Component(active composite)

ModBus(active leaf)

dataspace

PA(passive leaf)

execute

FQD(event leaf)

execute

synchronise

dataspace

execute

synchronise

dataspace

Figure 4. Tree view of the example.

3.3.1. SynchronizationThe model imposes a hierarchical structure on

compositions with a single composite componentat the top level. Since this component controlsthe whole application, it is always active. Thetop-level component can be interpreted as a treeof simple and composite components, some ofwhich are active, and others which are not.

The total number of threads in an applica-tion is the sum of the number of active compo-nents and the number of event components. Eachpassive component is fully under the control ofthe (unique) active component that contains it.The behavior of a component is given by its pre-defined exec procedure, which can be empty. Thecomplete behavior of a composite component con-sists of the generated schedule which executes thepassive components it contains and its own execprocedure in some given sequence.

The only difficulty is posed by the critical sec-tions where separate threads read or write shareddata. Contention occurs precisely wherever theexternal ports of an active component (whethersimple or composite) are connected to the portsof any other component. In order to strictlylimit the possible interference between concur-rent threads, all of the ports belonging to a singlethread, i.e., an active component and all the pas-sive components it contains, are grouped togetheras a single dataspace for that thread. Ports that

are shared between threads are replicated, and ex-plicitly synchronized by a sync procedure whichlocks the shared ports and updates the out-of-date copies. These sync procedures constitute theonly critical sections in an application.

A composite component therefore not onlyschedules the exec procedures of its passive sub-components and its own exec procedure, but alsothe sync procedures of its active and event sub-components.

This is illustrated in Figure 4. PA is passiveand thus uses the dataspace provided by Device.The FQD and ModBus components have their owndataspace, used by their exec procedure. Theirsync procedure has access to both dataspaces sothat they can be synchronized. Note that anypassive subcomponents of FQD would use thedataspace of FQD. Any passive subcomponentsof PA would use the dataspace provided by De-vice.

The synchronization semantics of the PECOS

component model has been formalized [ 19] usingPetri nets [ 20].

3.3.2. SchedulingWe can now summarize scheduling as follows:

• A composite component must provide aschedule for its direct subcomponents, i.e.,which specifies when to run its own execprocedure, the exec procedures of its passivesubcomponents and the sync procedures ofits active and event subcomponents.

• Each active and event component executesits own exec procedure and that of any sub-components in a single thread of control.

• Passive components are scheduled by theirparents.

• Synchronization procedures for active andevent components are scheduled by theirparents.

Figure 5 illustrates a sample run of a field de-vice over a period of 120 milliseconds. Since theperiod of the device is 60 ms the figure shows twoperiods in the runtime of the device. Becausethere are two active components and one event

6

120600 12 30 44 52 72 90 100 108

FQD.exec

FQD.sync

PA.execModBus.exec

ModBus.sync

1

2

3

ModBus. sync

PA.exec

FQD.sync

ModBus.exec

76

Figure 5. Possible Execution trace for the exam-ple.

component in the example, there are three con-current threads: one for the Device component(Task 1), one for the ModBus component (Task2), and one for the FQD component (Task 3). As-sume that the priority of task 1 is higher than thepriority for task 2, which is higher than the pri-ority of task 3.

In the first period of task 2, the sync procedureof the ModBus is executed, followed by the execprocedure for the passive PA component and thesync procedure for the FQD component. Whenthey are finished executing, the lower prioritytask 3 executes the exec procedure of the ModBuscomponent. Since there is no event that triggersthe exec procedure for the FQD component, noth-ing happens in task 3. In the second period of thedevice more or less the same happens except thatan event triggers the exec procedure of the FQDcomponent. That interrupts the behavior in task2, since it has a higher priority. When it is fin-ished, task 2 resumes, followed by task 3.

3.4. Checking Non-Functional Require-ments

One of the key challenges for the PECOS com-ponent model was to support timing analysisto verify whether a component composition isschedulable and can meet its deadlines. Two pos-sibilities exist to do this. Either the internal be-havior of components can be modeled (for exam-ple using CSP [ 12] or Petri nets [ 20]) or thecomponents can be instrumented at runtime toobtain execution times. The latter approach waschosen, since it was well-understood and corre-

sponded to best practice.The input for tools checking non-functional re-

quirements is always a concrete component com-position where the property bundles of compo-nents contain runtime information. This runtimeinformation consists of the worst-case executiontimes of components, and optionally the maxi-mum blocking times for active or event compo-nents.

Two complementary checks are performed us-ing this information: rate monotonic analysis(RMA) and schedule verification. The RMA ver-ification ensures that the overal component com-position has time enough to run. Schedule verifi-cation ensures that within a task, activities can bescheduled sequentially. Both checks are comple-mentary, since the RMA verification works on thelevel of the complete device, but can by itself notensure that the schedule for a task is feasible. Theschedule verification can ensure that the schedulefor a task is feasible, but not that there is enoughtime to run all the activities (taking other tasksand task-switching overhead into account).

The next two sections explain the two comple-mentary checks in detail and applies them to theexample field device.

4. Timing Verification

Given a component composition, rate mono-tonic analysis (RMA) is used to check whetherall the components involved in the compositionmeet their deadlines. This section briefly intro-duces RMA, and then shows the mapping fromthe component model to RMA and how this isused in practice.

4.1. Rate Monotonic AnalysisRate monotonic analysis (RMA) [ 23] consists

of a number of simple, practical techniques togenerate or verify schedules for a set of real-timetasks. RMA algorithms assign a fixed priorityto each task and assign higher priorities to taskswith shorter periods. It then provides differentTheorems to check whether tasks can meet theirdeadlines depending on whether the tasks are (i)periodic and independent, (ii) mixed periodic andaperiodic, or (iii) interacting [ 23]. For PECOS in-

7

(1) each resource has a ceiling priority definedas the highest priority of all the potential tasksthat use the resource. (2) A task gets the lockon a resource if this resource is not locked. Thetask then inherits the resource’s ceiling priorityplus one. It can then proceed with the execu-tion of the critical section. If the lock could notbe acquired, the task is blocked up to the pointwhere the blocking task unlocks the resource andretrieves its assigned priority.

Figure 6. Rules employed by the highest-lockerprotocol.

teracting tasks are needed, because of the syncprocedures of active and event components.

The difficulty with interaction is that high pri-ority tasks should be minimally delayed by lowerpriority tasks when both are contending for thesame resources. But when there are differenttasks with different priorities that can freely lockresources, the periods where tasks of a higher pri-ority are blocked by tasks of a lower priority be-come unpredictable. This situation is called un-bounded priority inversion. Since the blockingtimes become unpredictable, no timing verifica-tions can be done.

Therefore RMA assumes that the implementa-tion uses real-time synchronization protocols thathave two important properties: freedom from mu-tual deadlock, and bounded priority inversion,where at most one lower priority task can block ahigher priority task. Examples of such protocolsare the priority ceiling protocol or the highest-locker protocol (shown in Figure 6).

When such real-time synchronization protocolsare used, a theorem known as RMA theorem 4(see Figure 1) can be used to check whether a setof interacting tasks meets its deadlines. Note thatthe other RMA theorems (one to three) either as-sume non-interacting tasks or only provide crudeapproximations.

A set of n periodic tasks using an appropri-ate real-time synchronization protocol will alwaysmeet its deadlines, for all task phasings, iff

∀i, 1 ≤ i ≤ n,

min(k,l)inRi

i−1∑j=1

Cj

⌈lTk

Tj

⌉+ Ci + Bi ≤ lTk

where Ci, Ti, and Bi are the worst-case executiontime, period and blocking time for a task i, and

Ri ={

(k, l)|1 ≤ k ≤ i, l = 1, ...,⌊

Ti

Tk

⌋}Table 1RMA Theorem 4

4.2. RMA based Timing AnalysisTo use RMA to verify a component composi-

tion a mapping is needed from components toRMA tasks. The example used is the same as de-scribed in Section 2.1 and used in the rest of thepaper, but extended with runtime figures. Thisis shown in Figure 7. It is the input used forboth the RMA analysis and the schedule analysisdiscussed in Section 5.

Mapping component behavior to tasks.

With a passive component P, a (periodic) taskis associated that has a worst-case execution time,period and deadline as defined by Ps timing prop-erty bundle. With an active or event componentA, two tasks are associated: a task Tsync for thesync procedure and a task Texec for the exec pro-cedure. The worst-case execution time, periodand deadline of Tsync and Texec are given by thesync and exec part of the timing bundle of A.

Note that RMA only allows tasks that are pe-riodic, an inherent difficulty when applying RMAin a context where aperiodic tasks exist. To solvethis problem lots of research is done in mappingaperiodic behavior to periodic tasks [ 23, 15].Proposed solutions differ in desired response time,overal optimality of the scheduling, the ability torecuperate slack time left by non-utilized aperi-odic tasks, and run-time overhead of the decision

8

Device Synchronisation: wcet: 0 Execution: wcet: 0, period:60, priority:2 order: FQD, ProcessApplication, ModBus

FQD Synchronisation: wcet: 10 Execution: wcet:15, period:30, priority:3

actualPosition

velocityPA Execution: wcet: 5

theActualPosition

theVelocity

frequencyToSet

ModBus Synchronisation: wcet: 5, blocking:5 Execution: wcet:20, period:500, priority:1

frequencyToSet

Figure 7. The example from Figure 2 extendedwith the runtime information for the components.All numbers indicate milliseconds, wcet stands forworst-case execution time.

algorithm. One class of solutions are sporadicservers, that have as advantage that they have astraight-forward implementation with very littleruntime overhead. A sporadic server is equivalentto a regular periodic task from a theoretical pointof view and thus fully compatible with RMA al-gorithm. In the example there is one aperiodiccomponent, ModBus, of low priority that we mapto a sporadic server task with a long deadline of500 (taskT5).

Assigning Priorities to tasks.

Then priorities need to be assigned. RMA spec-ifies that the shorter the period (worst-case ex-ecution time) of a task, the higher its priority.For tasks with the same period, arbitrary priori-ties are chosen so that the tasks can be orderedaccording their priority. So when mapping themodel to RMA the timing bundles are processedto make sure that these conditions hold. In theexample all the priorities are given, so no priori-ties have to be chosen.

Deriving blocking times.

All tasks need blocking times. Tasks associatedwith passive components always have a blockingtime of 0. But tasks for active or event compo-nents can indicate the time they need to lock thedata space during synchronization or execution.When those blocking times are not given, worst-case blocking times are derived using the priori-ties and worst-case execution times. To explainhow blocking times are extracted, assume the fol-lowing setup: A is a composite active or eventcomponent that has n subcomponents. The syncprocedure of A is called Async. The exec proce-dure is called Aexec. Every subcomponent hasprocedures that are scheduled by A. Call theseprocedures S1 to Sm, where m ≥ n (since someof the subcomponents can be composite compo-nents). Now call S the set consisting of Async andS1 to Sm. The datastore can thus be accessed si-multaneously by Aexec and at most one elementof S. To see which blocking can occur, S is splitin two subsets: L is the subset of S where theelements have a priority that is lower than thepriority of Aexec; H is the subset of elements thathave a higher priority. With this division made,worst-case blocking times can be given for thoseelements that do not explicity provide values:

• Elements in L are the ones that can blockAexec. The worst-case blocking time of eachelement in L that does not specify an ex-plicit value is either the blocking time ofexec (when it is given) or the execution timeof exec.

• Elements in H are the ones that can beblocked by Aexec. The worst-case blockingtime of Aexec is the maximum of the worst-case execution times and explicit blockingtimes of the elements in H.

In the example, the blocking time for PA.execis 0 since it is a passive component. ModBus.exechas the lowest priority in the example, so itsblocking time is also 0. For the FQD component,no blocking times are specified. The worst-caseblocking time for the FQD.exec is 10 (the worst-case execution time of the FQD.sync), and is 0 for

9

Behavior wcet period blockingFQD.exec C1 = 15 T1 = 30 B1 = 10FQD.sync C2 = 10 T2 = 60 B2 = 0PA.exec C3 = 10 T3 = 60 B3 = 0ModBus.sync C4 = 5 T4 = 60 B4 = 5ModBus.exec C5 = 20 T5 = 500 B5 = 0

Table 2The result of mapping the component example toinput for doing a RMA analysis

FQD.sync. Then the tasks are ordered from high-est to lowest priority, resulting in Table 2. Thistable is the actual input for the RMA analysis.

Applying the theorem.

Theorem 4 can now be applied on the tasksobtained from the component model, since everytasks has a worst-case execution time, period andblocking time. The result of the analysis indi-cates whether the component composition givencan meet its overall deadlines.

In the example the input for theorem is givenby Table 2. The results of fitting the numbersfrom the table in the theorem are not shown here,but the result is that the equation holds. Thisassures us that globally there is enough time torun this component composition.

5. Schedule Generation and Verification

RMA assumes a set of tasks that run concur-rently. However, as explained in Section 3.3.2,not all tasks run concurrently and hence check-ing the global timing properties is not enough.The model associates a thread with each ac-tive and event component, in which each execand sync procedure has to be run (depending onthe nesting of the components), and in what or-der (through the schedules specified in compos-ite components). But whether it is possible tofit these behaviors sequentially in each threadneeds to be checked by a schedule verificationtool. Since this is essentially a resource alloca-tion problem, constraint solving is an appropriatesolution.

This section first explains constraint solving,

FQDexec

FQDsync

PAexec

ModBusexec

ModBussync

ModBussync

ModBussync

task2

task1

task3

period

start>0 task = nr

task = nrtask = nr task = nr

task = nr

task = nr task = nrend < period

end < period

end < period

start > end

start > end start = end + 20

start = end + 20

start>0 start>0

Figure 8. Constraint network for the example.The circles are variables for the activities (white)and for device information (grey). The connec-tions are constraints on those variables.

and then shows how to map the component modelto a constraint network.

5.1. Constraint SolvingThe classical definition of a constraint is simply

a relation between variables that should be main-tained at all times [ 13, 4]. There are differentmechanisms to express and solve constraints, adiscussion of which falls outside the scope of thispaper. Generally speaking constraint solving canbe divided in two categories. First of all there areapproaches based on logic programming, in par-ticular Constraint Logic Programming (CLP) [13]. Second there is a number of (numerical) in-cremental constraint solvers that have primarilybeen applied in the context of graphical user in-terfaces [ 8, 4]. After experimenting with both wedecided to go with a CLP approach because it al-lows us to generate all possible schedules, whereasincremental constraint solving techniques onlygive a single possible schedule.

5.2. Using CLP to Generate and VerifySchedules

To use CLP to verify or generate a schedule, acomponent model needs to be translated to a con-straint network that can be solved. This section

10

explains the mapping from the component modelto a constraint network. Applying the mappingto the example yields a network as shown in Fig-ure 8.

With every sync or exec procedure one or moreactivities are associated. How many activities areneeded depends on the period given for the behav-ior and the overall time for the schedule since theperiod specifies the interval at which the compo-nent expects to be executed. For example, whena component specifies that its execution behaviorhas a period of 20 milliseconds, and the scheduleis 60 milliseconds long, the execution behavior hasto be executed three times, separated by 20 mil-liseconds. So this execution behavior is mappedto three activities, with constraints that expressthe distance between them.

Then the activities need to be assigned tothe appropriate tasks. Each activity thereforehas a task number, and those task numbers areconstrained by traversing the component tree.Whenever an active or event component is en-countered, the activity for the exec procedure isassigned to a new task, together with the activ-ities for the subcomponents (until one of thosesubcomponents is an active or event componentagain). The sync procedure inherits the task ofthe parent of the component.

Finally the order of components is codified asconstraints on the appropriate activities. Anyother information on starting times of compo-nents is also taken into account. For example,specifiying that a certain execution behavior com-ponent should start at 20 milliseconds is mappedto a constraint that specifies that the start of theactivity corresponding to that execution behaviorshould be 20.

We used ECLiPSe, a constraint logic program-ming language, to implement the mapping, re-sulting in a constraint network as shown in Fig-ure 8. Note that each of the variables in thisnetwork has a finite domain. The domain for thetask variables is between 1 and the number oftasks needed. The domain for the start, end andworst-case execution times in each of the activ-ity variables is between 0 and the period of thedevice. To solve this network we employ a tech-nique known as edge finding [ 6], a general con-

60300 5 10 15 20 25 35 40 45 50 55

FQD.exec FQD.syncPA.execModBus.exec

ModBus.syn

1

2

3

Figure 9. Graphical depiction of a result fromrunning the schedule verification tool. It showsthe sequential ordering of behaviors for the threetasks in the model.

straint satisfaction technique directly available inECLiPSe as a library. This technique derivesstronger bounds on the starting times of the activ-ities, while making sure that they do not overlap.The result of solving the network is either a sched-ule for each task in the component model or a fail-ure. A failure indicates that there is at least onetask for which no schedule could be found. Whenat least one solution can be found, a sequentialschedule for each thread separately is found. Oneof these solutions for our example device is shownin Figure 9. Finding one static schedule for thewhole device is not possible because field devicesneed active and event components. For simpledevices, only passive components can be used in-side the field device, and then the solutions of theschedule verification yield the static schedule forthe overall device.

Note that since a CLP language is used, any in-complete information is regarded as a logic vari-able that needs to be solved. For example, theconstraint network can be used to find the maxi-mum worst-case execution times that are possiblefor one or more components in a composition. Orschedules can be seen for different orders for sub-components, so that the developer can select themost appropriate one. Hence the schedule verifi-cation tool can also be used to generate schedulesor to have an interactive way of building sched-ules.

11

6. Discussion and Related Work

According to Szyperski [ 25], component-basedsoftware development now promises to “deliverreusable, off-the shelf software components forincorporation into large applications”. Compo-nents are typically defined as entities that encap-sulate some internal representation with one ormore interfaces. This enables binary compositionof components, usage of multiple implementationlanguages, easier distribution of components andeven dynamic reconfiguration of applications atruntime [ 24, 17].

All these approaches, however, need some run-time infrastructure to work. For example, to sup-port distribution, centralized or distributed nam-ing services have to be used. Unfortunately, thecontext of field devices at this time does not al-low for such runtime infrastructure. The PECOS

component model therefore focuses on static com-position, and assumes only a runtime environ-ment that supports synchronous passing of dataaccording to a blackboard-like architecture.

There are also similarities between the PECOS

approach and architectural description languages(ADLs). An ADL is a language for modellinga software system’s conceptual architecture interms of components, connectors, and configura-tions [ 9]. An ADL typically embodies a formalsemantic theory that allows certain analyses tobe performed. Some ADLs focuss on supportingdistributed applications (such as Darwin/Regis [16], Rapide [ 14]). Others focuss on describing thesemantics of the internals of components in someformalism to do certain verifications (for exampleWright [ 2]).

In the context of PECOS formal approaches(like Timed Petri nets [ 26], real-time object-oriented modeling [ 21], real-time UML [ 22] syn-chronous languages like Esterel [ 5] and Lustre [10], StateCharts [ 11], or Piccola [ 1]) that de-scribe the behaviour of components in order toverify runtime and synchronization aspects werenot applicable. This was motivated by the factthat the approach had to be usable by the cur-rent developers that had no experience with for-mal techniques. Instead the runtime aspects ofthe components are measured, a technique with

which the developers have a lot of experience andhave already well-proven hard- and software so-lutions.

The main similarities between the PECOS com-ponent model and general-purpose componentmodels and ADLs reduce to:

• the behavior of components is black-box,and completely encapsulated in the compo-nents,

• the interface of a component, is completelyseparate from its implementation, and fromits interconnection with other components,

• the model is language-independent, thoughcomposition of heterogeneous componentsis not supported.

The main differences can be summed up as:

• components have a single interface that con-sists of the data that it requires/provides.There is no interface for behavior, since themodel is fine grained and a component en-capsulates a single piece of behavior.

• model elements have property bundles thatare used to attach meta-information tocomponents.

• the model enables timing verification withrate monotonic analysis and schedule veri-fication and generation.

7. Conclusion

Modern development techniques have been dif-ficult to apply to embedded software due to themismatch between the severe constraints posedby the target devices, and the generous assump-tions required by the techniques. The PECOS

project has developed a viable approach to en-able CBSD for a class of embedded systemsknown as field devices. Rather than attempt-ing to adapt existing component models to thedomain of field devices, a new, pragmatic compo-nent model was developed that reflects best prac-tice in terms of component concepts. With mem-ory being a scarce resource and computing powerbeing severely limited, the model is data-centric

12

and eliminates concurrency and synchronizationwherever possible. However, it supports passive,active and event components and enables timinganalysis and schedule verification to ensure thatcomponent compositions can be deployed success-fully.

Although a full validation of the PECOS ap-proach was not possible within the scope of theproject, the ideas have been convincingly testedin the context of the field device demonstrator,and plans are underway to apply the model tofurther case studies.

Results of the project are available fromwww.pecos-project.org.

Acknowledgment. Thanks to Andrew Blackfor many useful discussions during his visit at theSoftware Composition Group lab.

REFERENCES

1. F. Achermann and O. Nierstrasz. Applica-tions = Components + Scripts – A Tour ofPiccola. In Software Architectures and Com-ponent Technology. Kluwer, 2001.

2. R. J. Allen. A Formal Approach to Soft-ware Architecture. Ph.D. thesis, School ofComputer Science, Carnegie Mellon Univer-sity, Pittsburgh, 1997.

3. G. Arevalo, S. Ducasse, O. Nierstrasz,P. Liang, and R. Wuyts. Verifying timing,memory consumption and scheduling of com-ponents. PECOS deliverable D2.2.6-3, Uni-versity of Bern, 2002.

4. G. J. Badros and A. Borning. The cas-sowary linear arithmetic constraint solving al-gorithm: Interface and implementation, 1998.University of Washington, TR 98-06-04.

5. G. Berry. The foundations of Esterel. MITPress, 2000.

6. J. Carlier and E. Pinson. A practical use ofjackson’s preemptive schedule for solving thejob-shop problem. Annals of Operations Re-search, (26), 1990.

7. Pecos Consortium. PECOS in a Nutshell.http://www.pecos-project.org/public docu-ments/pecosHandbook.pdf. 2002.

8. B. Freeman-Benson, J. Maloney, andA. Borning. An incremental constraint

solver. Comminications of the ACM,33(1):55–63, 1990.

9. D. Garlan, R. T. Monroe, and D. Wile. Acme:Architectural description of component-basedsystems. In Foundations of Component-Based Systems. Cambridge Press, 2000.

10. N. Halbwachs, P. Caspi, P. Raymond, andD. Pilaud. The synchronous data flow pro-gramming language lustre. In Proceedings ofthe IEEE, volume 79, September 1991.

11. D. Harel. On visual formalisms. CACM,31(5):514–530, May 1988.

12. C.A.R. Hoare. Communicating SequentialProcesses. Prentice-Hall, 1985.

13. J. Jaffar and M. Maher. Constraint logic pro-gramming : a survey. The Journal of LogicProgramming, (19,20):503–581, 1994.

14. J. J. Kenney. Executable Formal Modelsof Distributed Transaction Systems based onEvent Processing. PhD thesis, Stanford Uni-versity, 1995.

15. M. H. Klein, T. Ralya, B. Pollak, R. Obenza,and M. G. Harbour. A Practitioner’s Hand-book for Real-Time Analysis: Guide to RateMonotonic Analysis for Real-Time Systems.Kluwer Academic Publishers, 1993.

16. J. Magee, N. Dulay, and J. Kramer. Regis:A constructive development environment fordistributed programs. IEE/IOP/BCS Dis-tributed Systems Engineering, 1(5), 1994.

17. R. Monson-Haefel. Enterprise JavaBeans.O’Reilly, 1999.

18. Motorola. Fast quadrature decode tpu func-tion (FQD). TPUPN02/D, 2002.

19. O. Nierstrasz, G. Arevalo, S. Ducasse,R. Wuyts, A. Black, P. Muller, C. Zeidler,T. Genssler, and R. Born. A componentmodel for field devices. In Proceedings ofWorking Conference on Component Deploy-ment. ACM, 2002.

20. J. L. Peterson. Petri nets. ACM ComputingSurveys, 9(3), 1977.

21. B. Selic, G. Gullekson, and P. T. Ward. Real-Time Object-Oriented Modeling. John Wiley& Sons, 1994.

22. B. Selic and J. Rumbaugh. Using UML formodeling complex real-time systems, 1998.

23. Sha, Klein, and Goodenough. Rate Mono-

13

tonic Analysis for Real-Time Systems. Foun-dations of Real-Time Computing: Schedul-ing and Resource Management. Kluwer Aca-demic Publishers, 1991.

24. J. Siegel. CORBA Fundamentals and Pro-gramming. John Wiley & Sons, 1996.

25. Clemens A. Szyperski. Component Software.Addison Wesley, 1998.

26. J. Wang. Timed Petri Nets. Kluwer Aca-demic Publishers, 1998.