The semantics of device specificiations are given in terms of Time Parametric
Modal Specifications (Chapter 3). However, we do not need to go into details
to describe how the devices relate to the timed-input and output event streams
used here. Each device specification is fully captured by a digital TPMS of its
behavior. Each digital TPMS models asetof input-output timed automata (IOTA)
with digital semantics. We require each IOTA to be deadlock and timelock free, thus each IOTA induces a set of infinite timed input and output words.
Definition 4.4.11 (Timed Word). A timed word is a (possibly infinite) sequence
of alternating actions and delaysd≥0whered∈R. We say that a timed-word is
digital if it is always the case thatd∈N. For example:
0
Is a digital timed-word.
If a wordwcontains only delays and actions from a IOTA’s input alphabet we
saywis a timed-input word. Likewise ifwcontains only actions from the output
alphabet it is a timed-output word.
Each IOTA from an ODSDL device specification is input-enabled by construc- tion so we can convert the timed-event output stream of an ODSDL program into an infinite timed word over the specification’s inputs. Likewise we can convert the timed-words over the outputs of a IOTA into an input timed-event stream for the ODSDL program.
Definition 4.4.12 (Stream Semantics of Devices). Let X be the TPMS corre-
sponding to device specification D and let JXK be the set of IOTAs implied by
X. Let W be the union of all the timed words of all the IOTA inJXK. The the
stream semantics of device specification D is given by the greatest relation RD
that satisfies the following: (sin, sout) ∈ RD ifsin is the timed-event stream cor-
responding to the input-projection of some infinite word wi ∈ W and sout is the
timed-event stream corresponding to the output projection ofwi.
4.5
Related Work
Programs executing as part of a larger cyber-physical system typically have real- time requirements: in order to be correct they must perform the correct computa- tions at the correct time. This presents major challenges for program portability and program verification. Real-time programs are typically not portable because their timing is dependent on the processor and how the underlying operating sys-
program is run on a different processor or operating system it will have different timing characteristics which in turn could cause the program to violate its timing
requirements. Even if a program meets its timing requirements (e.g.,always com-
pletes before its deadline) execution non-determinism (e.g., caused by operating
scheduling decisions or speculative effects in the processor) can make it difficult for developers to reproduce bugs or to relate testing results back to assurance claims. Difficulties with portability and verifiability of real-time code drive up the development costs for real-time software systems. Furthermore, the platform approach to on-demand systems requires portable real-time programs.
In the 1990’s DARPA invested in the MetaH [177, 176] program to address
problems surrounding real-time program portability and verifiability. MetaH re- sulted in a set of tools and programming constructs for the development of dis- tributed real-time software systems. MetaH allowed developers to construct soft- ware systems out of components that communicate through ports. Each compo- nent may have a number of periodic or sporadic real-time tasks that do the actual processing. Tasks in MetaH can read or write to their container component’s ports. MetaH addresses time-determinism by assuming that tasks only share data via ports, and that the results of a computation are only “visible” at a task’s deadline (regardless when the computation actually finished). This ensures that computa- tions are time-deterministic if all the tasks of the software system are schedulable on the given platform. MetaH inspired the Architecture Analysis & Design Lan-
gauge (AADL) SAE standard [65] and many of MetaH’s features have found
their way into AADL.
In 2001 Henzingeret al.rediscovered many of MetaH’s determinism features
fairly accurate to think of Giotto as equivalent to the periodic subset of MetaH. There are, however, two major differences betweem Giotto and the periodic subset
of MetaH. First, Henzingeret al. provide formal operational semantics for Giotto
programs. Second, Giotto is not coupled to an underlying scheduler (MetaH as- sumed a form of rate-monotonic scheduling).
[58] describe the PTIDES deterministic programming model for distributed
real-time embedded software. PTIDES semantics are based on discrete event simulation: Programs in PTIDES consist of actor components which can com- municate with each other via ports and channels that link those ports. Whenever a PTIDES actor sends a message it is timestamped. The timestamp is used by the underlying PTIDES exection platform to ensure that each actor only processes
input messages in timestamp order [59, 189,188]. Because receipt of a message
triggers actor computation, PTIDES supports aperiodic execution. Periodic exe- cution can be achieved with a specialized clock actor that generates messages at period boundaries. Because PTIDES programs consist of communicating actors (as opposed to a collection of tasks) new schedulability techniques needed to be devised to asses the schedulability of PTIDES programs. Christos Stergio estab-
lished the decidability of PTIDES scheduling in his PhD dissertation [169]. He
showed that in general schedulability is no harder than the reachability problem for timed automata, and if only a subset of PTIDES is considered it is equivalent to earliest deadline first schedulability analysis.
For on-demand systems we want a programming model that is deterministic,
has precise formal semantics, is easy (i.e., efficient) for paltforms to schedule,
provides familiar programming constructs and allows for both periodic and ape- riodic computation. The programming model of MetaH (and AADL) don’t yet
have a complete and formal semantics. Giotto only allows periodic computation. While PTIDES has discrete event semantics these are never precisely given. For example it is unclear what should happen if an actor receives two events with
the same timestamp. Furthermore, PTIDES does not precisely couplemodel-time
with physical time: Actuators must receive their messages prior to the expiration of the timestamp, but when the actuator acts on the message is undefined (presum- ably it happens after, but not too long after, the timestamp). The actor construct
of PTIDES is also different from what most programmers are used to (i.e.,tasks).
Furthermore, the schedulability analysis of PTIDES programs can be quite com- plicated (both operationally and in terms of time-complexity) which is not suitable for a platform that must perform schedulability analysis on-demand.
Chapter 5
A Prototype Medical Application
Platform
In this Chapter we describe the Medical Device Coordination Framework (MDCF) and the MIDdleware Assurance Substrate (MIDAS). The combination of the MDCF and MIDAS results in a prototype MAP implementation designed to demonstrate the feasibility of key technologies essential to the viability of the MAP concept.
As discussed in Chapter 2, a MAP could host any number of safety- or privacy
critical applications. Ideally, the MAP certification criteria in a real on-demand
ecosystem would require that all MAPs satsify the following “high-assurance”
features:
1. Enforce a high degree of (potentially complete) of isolation and separation between independent applications and system components.
2. Employee sound techniques to secure sensitive (i.e., private data) and deter- mine the authenticity of devices and applications.
3. Utilize fault-tolerant (or fault resistant) hardware and algorithms.
4. Be verified & validated (possiiblly with formal, machine-checked, proofs)
to the highest level of assurance1.
While all the above are important for a real MAP, this chapter does not focus
on how each and every possiblehigh assurancefeature could be implemented and
incorporated into the MDCF/MIDAS. Indeed, many useful high assurance fea- tures (such as those listed above) have been studied extensively in the literature and in some cases are available in commercial products (see the related work Sec- tion 5.6.1). Instead, this chapter focuses on describing the platform capabilities
that are both new and necessary to makeourvision of a MAP ecosystem work.
A key challenge for any MAP is to provide determinism in a dynamic, open, and distributed environment. Most distributed systems with strict determinism re-
quirements are designed assuming the system itself will be static (i.e., the tasks
and data-flows that comprise the “digital” portion of the system are fixed from the factory). Consequently, most technology developed to enable determinism have not been designed to work for systems that are dynamic, open, and distributed. For example, the networking technology typically used in high assurance real-
time systems (e.g., the Time Triggered Architecture [113], Time Triggered Eth-
ernet, FlexRay [53], etc.) can provide the needed timing guarantees and inter-
component isolation but must be configured “offline”. Likewise, while there has been a number of promising distributed deterministic programming models devel-
oped (e.g., PTIDES) their execution strategies require complex procedures (both
operationally and computationally) for schedulability analysis which makes on-
line admission control difficult.
This chapter presents three contributions towards enabling strict determinism in an open, dynamic, and distributed system. The first is the MIDAS. MIDAS
combines Software Defined Networking (SDN) [136] with a publish/subscribe
communications abstraction. MIDAS enables programmers to specify timing con- straints on logical flows of data between producers and consumers. MIDAS then enforces the timing constraints and specified isolation by reconfiguring the un- derlying network packet switching infrastructure on the fly. The second contribu-
tion is adeterminizing scheduler that implements the DLT semantics of ODSDL
programs. The resource demands of the execution strategy employeed by the de- terminizing scheduler can be reduced to a traditional task-set specifciation which enables the use of relatively simple schedulability analysis techniques. The third contribution is a collection of minor modifications to existing real-time schedul- ing techniques. These minor modifications are necessary for us to use classic real-time scheduling theory with real COTS operating systems and networking hardware.
This Chapter is organized as follows. Section5.1gives a functional overview
of the software architecture of the MDCF/MIDAS. Section 5.2 gives a detailed
overview of the MIDAS Channel-Service. The MIDAS Channel-Service provides the hard real-time publish/subscribe communications primitives leveraged by the
determinizing schedulerto implement the DLT semantics in a distributed system.
Section 5.3 describes the overall operation of that determinizing scheduler and
how it achieves the LET semantics. Section 5.4 describes a variety of practical
scheduling techniques used by the MDCF/MIDAS to ensure that tasks and mes-
sages always meet their deadlines. Section 5.5 an evaluation and performance
Distributable Components Application
Manger
Device
Manager Resource Manager
Determinizing Scheduler
Real-Time Message Bus
App1 App1 App1
Figure 5.1: MDCF Software Architecture.
execution.
5.1
MDCF Architecture and Functional Overview
The MDCF/MIDAS is a set of integrated services intended to run on top of a traditional real-time operating system. These services work with each other, the underlying hardware and operating system to manage the lifecycle of MAP ap- plications and provide a predictable environement for those applications to exe-
cute in. Figure 5.1 shows the software architecture of the MDCF/MIDAS. The
MDCF/MIDAS is comprised of the MIDAS Real-Time Message Bus, a Device Manager, an Application Manager, and a Resource Manager that supports the De- terminizing Scheduler.