chapter 3 synoptic: a domain-speciﬁc modeling language for...

BookID 187219 ChapID 003 Proof# 1 - 17/05/10

Uncor

recte

d Proof

Chapter 3 1

Synoptic: A Domain-Specific Modeling 2

Language for Space On-board Application 3

Software 4

A. Cortier, L. Besnard, J.P. Bodeveix, J. Buisson, F. Dagnat, M. Filali, 5G. Garcia, J. Ouy, M. Pantel, A. Rugina, M. Strecker, and J.P. Talpin 6

3.1 Introduction 7

3.1.1 Context: Embedded Flight Software 8

This section describes the context of the SPaCIFY project and the various constraints 9that have been handled in the design and implementation of the Synoptic language 10toolset. 11

A. Cortier, J.P. Bodeveix, M. Filali, M. Pantel, and M. StreckerAQ1IRIT-ACADIE, Universite de Toulouse, site Paul Sabatier,118 Route de Narbonne, 31062 Toulouse Cedex 9, Francee-mail: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]

J.P. Talpin, J. Ouy, and L. BesnardIRISA-ESPRESSO, campus de Beaulieu., 35042 Rennes Cedex, Francee-mail: [email protected]; [email protected]

J. BuissonVALORIA, Ecoles de St-Cyr Cotquidan, Universite Europeenne de Bretagne,56381 Guer Cedex, Francee-mail: [email protected]

F. DagnatInstitut Telecom – Telecom Bretagne, Universite Europeenne de Bretagne,Technopole Brest Iroise, CS83818, 29238 Brest Cedex 3, Francee-mail: [email protected]

G. GarciaThales Alenia Space, 100 Boulevard Midi, 06150 Cannes, Francee-mail: [email protected]

A. RuginaEADS Astrium, 31 rue des Cosmonautes Z.I. du Palays, 31402 Toulouse Cedex 4, Francee-mail: [email protected]

S.K. Shukla and J.-P. Talpin (eds.), Synthesis of Embedded Software: Frameworks andMethodologies for Correctness by Construction, DOI 10.1007/978-1-4419-6400-7 3,c� Springer Science+Business Media, LLC 2010

[email protected]

[email protected]

[email protected]

[email protected]

[email protected]

[email protected]

[email protected]

[email protected]

[email protected]

[email protected]

[email protected]


Uncor

recte

d Proof

SPaCIFY Project

Satellite and Flight Software 12

A satellite is an unmanned spacecraft. The system architecture is usually specializedAQ2AQ3 13

according to the satellite mission. There are two main subsystems: the payload is 14an application equipment such as specific scientific instrumentation for instance; 15the platform consists of mechanical structure, sensors and actuators used by the 16payload and devices for communications with ground stations. The SPaCIFY project 17focuses on the flight software embedded in the satellite to manage its platform, 18also called on-board software. The flight software is a real-time software that pro- 19vides services that are common to whatever mission-specific payload the spacecraft 20is assigned. Typical services include reaching and following the desired attitude 21and orbit, managing thermal regulation systems, power sources, monitoring sys- 22tem status, managing on-board network (MIL-STD-1553, OBDH, SpaceWire), and 23communicating with ground stations. 24

Even after the satellite has been launched, flight software must be adapted. Satel- 25lites are subject to high energy particles that may damage hardware components. 26Such damages cannot be fixed except by installing software workarounds. Bug fixes 27and software updates should be propagated to flying satellites. In addition, mission 28extensions may require functional enhancements. 29

As flight software is critical to the success of the mission, space industries and 30agencies have worked on engineering processes in order to help increase reliabil- 31ity. For instance, the European Space Agency has published standards (ECSS-E-40) 32on software engineering and (ECSS-Q-ST-80) on product assurance. These stan- 33dards do not prescribe a specific process. They rather formalize documents, list 34requirements of the process and assign responsibilities to involved partners. Re- 35garding updates, standards stipulate for instance that the type, scope and criticality 36must be documented; that updates must be validated; and so on. Industries are free 37to come up with their own conforming processes. The SPaCIFY project defines such 38a process and supporting tools based on Model-Driven Engineering (MDE), syn- 39chronous languages and the Globally Asynchronous Locally Synchronous System 40(GALS) paradigm. 41

Kind of Model Used 42

Two main kinds of models are commonly used in order to design the platform 43software: on the one hand, the description of the platform itself, its hardware 44and software architecture, CPU, memory, storage, communication buses, sensors, 45actuators, hardware communication facilities, operating system, tasks, software 46communication facilities, and on the other hand, the command and control algo- 47rithms involved in the management of the platform. All these models have common 48features. First, the notion of mode is central to represent the various states or con- 49figurations of both hardware and software (for example: init, reset, on, low power, 50failure, safe). The modes and their management are usually expressed using finite 51automata. Second, the functional blocks, data exchange buses and signals are used 52to represent both the hardware and software architectures, and the command and 53control software.

54


Uncor

recte

d Proof

3 Synoptic: A DSML for Space On-board Application Software

However, the current models only provide a partial account of the constraints that 55the final system must satisfy. The designers usually encode these hidden constraints 56using the available constructs in the modeling languages, even if this was not the 57initial purpose of the construct used. This is usually the case for hard real-time 58constraints. The designers will rely on explicit management of the control-flow in 59dataflow models in order to manage the concurrency between the activities. But, 60the real timing constraints are not explicitly given in the model, they are handled 61by the designers who sequence the activities, but there is no real specification of the 62intended result. Thus it requires a very difficult verification phase that can only occur 63on the final target. This is the current main difficulty: using model constructs for 64other purpose than their intended ones without any formal, model-level, traceability 65to the initial constraints. 66

Models in Development Process 67

Currently, industrial main actors are relying on the Matlab toolboxes Simulink and 68Stateflow from “The MathWorks” [4] for expressing the command and control al- 69gorithms for the various sub-systems of the platform. These models are built by 70command and control engineers taking into account several kinds of constraints: 71

� The hardware which is usually known very early (in particular if it handles timing 72and synchronisation constraints related to sensors and actuators, which must be 73activated and will produce results in very precise timing patterns) 74

� The system mode management that impacts the execution of the various 75sub-systems 76

� The specification of the intended sub-system 77

The Simulink and Stateflow toolboxes allow a very wide range of modeling 78methods, from continuous partial differential equations to graphical functional 79specifications. Each industrial actor has a well defined process which defines the 80restricted subset of the modeling language that will be used at each phase of the 81development cycle. In the ITEA GeneAuto project [34], a subset of these toolboxes 82was defined that fits the needs for the modeling of space application from early de- 83sign to automated target code generation. The industrial partners of SPaCIFY took 84also part in GeneAuto. This subset aimed at providing a solid semantic background 85that would ease the understanding and the formal verification of models. This subset 86was chosen as an entry point for the design of the Synoptic language. One key point 87is the use of control-flow signals and events (called in Simulink function call events) 88in order to manage explicitly the sequencing of the blocks in dataflow models. This 89is an important point which is significantly different on the semantics side from the 90classical dataflow modeling languages such as SCADE [16] or RT-Builder [3] which 91do not provide a specific modeling construct for this purpose, but allow to encode 92it through empty data signals that are added between each block in the intended 93sequencing path. The key point is that the intended hard real-time constraints are 94not explicit. Thus it is mandatory to handle the control-flow construct exactly in its 95usual semantics not using an approximate encoding which only works most of the 96time but is not proven to work in all cases. 97


Uncor

recte

d Proof

SPaCIFY Project

Several studies have been conducted by industrial main actors regarding the mod- 98eling of hardware and software architecture. HOOD [30] and CCM [20] have been 99used for many real projects; AADL [6, 31], SysML [18] and UML/MARTE [29] 100have been evaluated using already existing projects that could be modeled and the 101results compared with the real systems. Once again, these languages provide a very 102wide range of modeling constructs that must be reduced or organized in order to be 103manageable. In the European ASSERT project [5], two tracks were experimented 104related to these languages, one mainly synchronous based on the LUSTRE [23] 105and SIGNAL [22] languages, the other mainly asynchronous based on the RAVEN- 106SCAR Ada [13] profile. The industrial partners from SPaCIFY were also part of 107ASSERT. Thus, the results of these experiments were used as entry points for the 108design of the Synoptic language. 109

In the current software development process, command and control models are 110formal specifications for the software development. These specifications have been 111validated by command and control engineers by using model simulators. The hard- 112ware architecture is currently defined in a semi-formal manner through structured 113documents. In the near future, models in AADL, or in a subset of SysML/UML/ 114MARTE similar to AADL, will be used to give a formal specification of the 115architecture. 116

Then, software engineers either develop the software and verify its conformance 117to the specification, or use automated code generators; the software is then split in 118parts that are mapped to threads from the RTOS. They are then scheduled accord- 119ing to the real-time constraints. The know-how of engineers lies in finding the best 120splitting, mapping and scheduling in order to minimize the resources used. 121

One of the purposes of introducing Model Driven Engineering is to be able 122to automate partly these manual transformations and the verification that their re- 123sult satisfies the specification. The Synoptic language should thus allow to import 124command and control models expressed in Simulink/Stateflow, hardware archi- 125tecture models expressed in AADL. The associated toolset should assist in the 126re-organisation of the model, and allow to express the mapping and scheduling. 127

3.1.2 Domain Specific Requirements 128

Real Time Constraints 129

Flight software is mainly responsible for implementing command and control laws. 130It is therefore a set of tasks performed at fixed time periods by a real-time kernel. 131Tasks perform the various management activities of the system. They have severe 132time constraints inherited from the command and control design by automation. The 133number of tasks varies depending on the approach adopted by the industry: Thales 134Alenia Space favors a large number of tasks (about 20–30 active tasks on a total of 13540–50); while EADS Astrium has a tendency to aggregate calculations, including 136frequency activation to reduce the number of tasks. 137


Uncor

recte

d Proof


Although the constraints are strong, the time scale is relatively slow. The 138activation periods of tasks in the flight software vary typically between 100 ms 139and 100 s. 140

Limited Hardware Resources Capacity 141

The computing resources embedded in satellites are limited. Thus, at the time of 142writing, the memory allocated to the flight software is generally under 10 MB. The 143binary image is also stored in a 1–2 MB EEPROM. 144

The computing power ranges from the 20 MIPS ERC32 processor up to nearly 145100 MIPS for the LEON 2 and 3 ones. Moreover, satellites operate in a hostile 146physical environment. Shocks, temperature variations, radiation, high energy par- 147ticle beams, damage and destroy electronic components, leading to rapid aging of 148embedded equipments. 149

Remote Observability and Commandability 150

Once a satellite has been launched, the only interventions currently possible are re- 151mote. Several scenarios have been identified that require maintenance interventions 152such as for example: 153

� The satellite, and therefore its embedded software, must survive as long as pos- 154sible to equipment aging and damages. Installing software workarounds is an 155economical means of continuing the mission as long as remaining equipments 156permit. Identifying problems is critical for the ground engineering teams that 157design such workarounds. 158

� Satellites are often still usable at the end of their initial mission. Updating the 159software is an economical way of achieving new mission objectives while recy- 160cling satellites. Therefore, ground operators must adapt the software to changing 161operational conditions. 162

� When a bug is detected in the software, its correction should be remotely installed 163without compromising the satellite. 164

These scenarios emphasize the need for remote monitoring and management of 165the flight software. Monitoring probes characteristics and state of satellite com- 166ponents (both hardware and software) and the physical environment. Management 167provides actions both at the application level, e.g., manoeuvre, and at the middle- 168ware level, e.g., software update. 169

The communication link between satellites and ground passes through ground 170stations. Since the SPaCIFY project has removed from its study the possibility of 171routing communications through other spacecrafts, being in range of a ground 172station is a prerequisite for connectivity. Characteristics (speed, visibility window)


Uncor

recte

d Proof

SPaCIFY Project

of the communication link depend of the orbit and of the mission. In general, we 173consider that it is rarely possible to download or upload a full image of the flight 174software. 175

A High Level of Quality and Safety 176

Given the fact that the only possible actions once the satellite has been launched 177are performed remotely, it is essential to ensure that the satellite is always able 178to respond to maintenance requests. In addition to verifying the software, defensive 179mechanisms are usually added as for example to restart computers in case of trouble. 180Indeed, given the radiation to which satellites are exposed during flight, high-energy 181particles can swap bits in memory. Several images of the software are also stored on 182board to be sure to have at least a version which is sufficiently functional to enable 183communications with the ground. 184

A Particular Software Industry 185

In addition to software business constraints, the design of flight software has its own 186peculiarities. 187

For certain classes of satellites, including scientific satellites, each satellite is 188a single unit, in fact a prototype. Indeed, every scientific mission has a specific 189objective, needing specific measuring equipment. 190

For other categories, including communications satellites, they are built in se- 191ries from a single design. However, due to the unpredictability of last minute client 192requests, manufacture, launch and space environment hazards, each satellite soon 193becomes again unique. This inevitably leads to a specific flight software for each 194different satellite. Even when multiple identical copies are initially installed on sev- 195eral satellites, such copies diverge to take into account the specific situation of each 196satellite and especially their failures and specific maintenance. 197

Furthermore, it is difficult to perform realistic testing of flight software. At best, 198simulations can give an indication of the software correctness. 199

GALS Systems 200

A satellite management software is usually divided in parts that are quite au- 201tonomous one from the other, even if they share the same platform and resources. 202Inside each of these parts, the subparts are most of the time strongly linked and 203must cooperate in a synchronous manner. These parts usually exchange informa- 204tion but with less time critical constraints, thus relying on asynchronous exchanges. 205These kind of system are usually called Globally Asynchronous, Locally Syn- 206chronous. Synoptic must provide some specific modelling elements to handle this 207structure. 208


Uncor

recte

d Proof


3.1.3 Synoptic: A Domain Specific Design Environment 209

Motivations 210

In collaboration with major European manufacturers, the SPaCIFY project (The 211SPaCIFY Consortium 2008) aims at bringing advances in MDE to the satellite flight 212software industry. It focuses on software development and maintenance phases of 213satellite lifecycles. The project advocates a top-down approach built on a domain- 214specific modeling language named Synoptic. In line with previous approaches to 215real-time modeling such as Statecharts and Simulink, Synoptic features hierarchi- 216cal decomposition in synchronous block diagrams and state machines. SPaCIFY also 217emphasizes verification, validation and code generation. 218

One key point to ease the long-term availability and the adaptability of the tools, 219is to rely on open-source technologies. 220

Overview of the SPaCIFY Development Process 221

To take into account the domain specific requirements and constraints presented in 222the previous section, the SPaCIFY project proposes to introduce models inside the 223design and maintenance processes of the on-board applications. Thus, the space 224domain may benefit from technologies developed in the context of Model Driven 225Engineering for processing, handling and analyzing models. It therefore takes a shift 226from current practices based on documents to a tool-supported process built around 227formal models. 228

The Fig. 3.1 summarizes the major steps of the proposed development and de- 229sign process. The central models are described in the Synoptic domain specific and 230

Fig. 3.1 Sketch of the SPaCIFY development cycle for on-board software


Uncor

recte

d Proof

SPaCIFY Project

Fig. 3.2 Code generation and execution platform (middleware)

formal language defined by the project. The process promotes vertical and hori- 231zontal transformations. The vertical transformations sketch the refinements and the 232enrichments of Synoptic models. The horizontal transformations consist of trans- 233lation transformations to formal models (Altarica [1], SME [9] models) that are 234equipped with specific verification, code generation or simulation tools. 235

The initial Synoptic model, resulting from the automated transformation of 236Simulink/Stateflow models previously designed by control engineers, is enriched 237by non-functional properties derived from textual requirements. 238

Using the hardware specifications, the Synoptic model is further enriched by the 239hardware model of the system. Based on hardware and software constraints, the 240dynamic architecture can be derived. 241

Finally, the resulting model includes the different views of the system (software, 242hardware, dynamic architectures) and mappings between them. This last model is 243used to generate the source code and to configure the middleware of the embedded 244application. At each step, analysis and verifications can be performed. The transfor- 245mations of models used in the refinement process formalize the expertise acquired 246by the industry. 247

Figure 3.2 focuses on the code generation phase. At this phase, the model of 248the application is initially translated into a SME model. Code generation itself is 249performed by the Polychrony compiler [21]. The generated code targets the use of a 250middleware specifically designed for the SPaCIFY project. 251

Contents of the Chapter 252

This chapter is organized as follows. Section 3.2 introduces the main features of 253the Synoptic DSML with a particular focus on the functional sub-language of 254Synoptic, called Synoptic core. Synoptic core permits to model synchronous is- 255lands. They communicate through asynchronous shared variables (called external 256variables) managed by the middleware. A simplified case study is used to present 257the various concepts introduced. Section 3.3 describes the formal semantics and 258the polychronous model of computation of the Synoptic core which is based on 259the synchronous dataflow language SIGNAL [7]. Section 3.4 focuses on middle- 260ware aspects. The architecture of the execution platform, the middleware kernel, 261external variables, and the reconfiguration service of the middleware are discussed. 262Section 3.5 concludes the main contribution of the project and gives an outlook on 263future investigations. 264


Uncor

recte

d Proof


3.2 Synoptic: A Domain Specific Modeling Language 265

for Aerospace Systems 266

3.2.1 Synoptic Overview 267

Synoptic is a Domain Specific Modeling Language (DSML) which aims to support 268all aspects of embedded flight-software design. As such, Synoptic consists of het- 269erogeneous modeling and programming principles defined in collaboration with the 270industrial partners and end users of the SPaCIFY project. 271

Used as the central modeling language of the SPaCIFY model driven engineer- 272ing process, Synoptic allows to describe different layers of abstraction: at the 273highest level, the software architecture models the functional decomposition of the 274flight software. This is mapped to a dynamic architecture which defines the thread 275structure of the software. It consists of a set of threads, where each thread is charac- 276terized by properties such as its frequency, priority and activation pattern (periodic, 277sporadic). 278

At the lowest level, the hardware architecture permits to define devices (proces- 279sors, sensors, actuators, busses) and their properties. 280

Synoptic permits to describe three types of mappings between these layers: 281

� Mappings which define a correspondence between the software and the dynamic 282architecture, by specifying which blocks are executed by which threads 283

� Mappings which describe the correspondences between the dynamic and hard- 284ware architecture, by specifying which threads are executed by which processor 285

� Mappings which describe a correspondence between the software and hardware 286architecture, by specifying which data is transported by which bus for instance 287

Figure 3.3 depicts the principles discussed above. 288

Fig. 3.3 Global view: layers and architecture mappings


Uncor

recte

d Proof

SPaCIFY Project

Our aim is to synthesize as much of these mappings as possible, for example 289by appealing to internal or external schedulers. However, to allow for human inter- 290vention, it is possible to give a fine-grained mapping, thus overriding or bypassing 291machine-generated schedules. Anyway, consistency of the resulting dynamic archi- 292tecture is verified by the SPaCIFY tool suite, based on the properties of the software 293and dynamic model. 294

At each step of the development process, it is also useful to model different ab- 295straction levels of the system under design inside a same layer (functional, dynamic 296or hardware architecture). Synoptic offers this capability by providing an incremen- 297tal design framework and refinement features. To summarize, Synoptic deals with 298dataflow diagrams, mode automata, blocks, components, dynamic and hardware ar- 299chitecture, mapping and timing. 300

In this section we focus on the functional part of the Synoptic language which 301permits to model software architecture. This sub-language is well adapted to model 302synchronous islands and to specify interaction points between these islands and the 303middleware platform using the concept of external variables. Synchronous islands 304and middleware form a Globally Asynchronous and Locally Synchronous (GALS) 305system. 306

Software Architecture 307

The development of the Synoptic software architecture language has been tightly 308coordinated with the definition of the GeneAuto language [34]. Synoptic uses es- 309sentially two types of modules, called blocks in Synoptic, which can be mutually 310nested: dataflow diagrams and mode automata. Nesting favors a hierarchical design 311and allows to view the description at different levels of details. 312

By embedding blocks in the states of state machines, one can elegantly model op- 313erational modes: each state represents a mode, and transitions correspond to mode 314changes. In each mode, the system may be composed of other sub-blocks or have 315different connection patterns among components. Apart from structural and behav- 316ioral aspects, the Synoptic software architecture language allows to define temporal 317properties of blocks. For instance, a block can be parameterized with a frequency 318and a worst case execution time which are taken into account in the mapping onto 319the dynamic architecture. 320

Synoptic has a formal semantics, defined in terms of the synchronous language 321SIGNAL [9]. On the one hand, this allows for neat integration of verification en- 322vironments for ascertaining properties of the system under development. On the 323other hand, a formal semantics makes it possible to encode the meta-model in a 324proof assistant. In this sense, Synoptic will profit from the formal correctness proof 325and subsequent certification of a code generator that is under way in the GeneAuto 326project. Synoptic is equipped with an assertion language that allows to state desired 327properties of the model under development. We are mainly interested in properties 328that permit to express, for example, coherence of the modes (“if component X is 329


Uncor

recte

d Proof


in mode m1, then component Y is in mode m2” or “. . . can eventually move into 330mode m2”). Specific transformations extract these properties and pass them to the 331verification tools. 332

3.2.2 Software Architecture Models 333

One typical case study under investigation in the project is a generic satellite po- 334sitioning software, Fig. 3.4. It is responsible for automatically moving the satellite 335into a correct position before starting interaction with the ground. 336

The specification of the central flight software (OBSW), consists of the compo- 337sition of heterogeneous diagrams. Each diagram represents one specific aspect of 338the software’s role. The OBSW module is controlled by a remote control telecom- 339mand TC 001 and receives attitude and position data (POS Data and ATT Data) from 340sensors through the middleware. 341

The Attitude and Orbit Control System (AOCS) is the main sub-module of the 342central flight software, Fig. 3.5b. The AOCS automaton controls its operational 343modes for specific conditions. It is either in nominal mode or in SAFE mode, 344Fig. 3.5c. The safe mode is characterized by a rude pointing of satellite equipments 345(solar panels, antennas). It computes the command to be sent to the thrusters to 346maintain a correct position and attitude. 347

3.2.2.1 Block Diagram: Dataflow, Automaton and External Blocks 348

A Synoptic model is a graphical block-diagram. A Synoptic block-diagram is a 349hierarchy of nested blocks. As such, you can navigate through different levels of 350abstraction and see increasing levels of model details. A block is a functional unit 351that communicates with other blocks through its interface. 352

Fig. 3.4 Satellite positioningsoftware

this

figur

ew

illbe

prin

ted

inb/

w


Uncor

recte

d Proof

SPaCIFY Project

OBSW : On Board Software

a

b

AOCS

c

SAFE : AOCS safe mode

d

Legend

Fig. 3.5 A typical case study: satellite positioning software


Uncor

recte

d Proof


Block Interface 353

A block interface consists of communication ports. A port can be either an event 354port or a data port and is characterized by its direction (in or out). Data ports can 355be typed using simple data types. However, typing data ports is optional in the early 356stages of design to give the designer the flexibility to describe abstract models. 357

As shown in Fig. 3.6, which represents a part of the Synoptic meta-model, it 358is possible to encapsulate a set of ports within a single entity called group of 359ports (PortGroup in Fig. 3.6). A group of ports is used to group a set of ports 360which are conceptually linked. As specified by the synchronized property of 361the PortGroupDecl meta-model class, it is possible to specify a synchronization 362constraint on ports constituting the group. 363

A block interface can be implemented by different types of blocks: dataflows, 364automata or externals, Fig. 3.7. 365

Dataflow 366

A dataflow block models a dataflow diagram. It embodies sub-blocks and specifies 367data or event flows between them. A flow is a directed connection between ports 368of sub-blocks. A sub-block is either an instance of dataflow, automaton or external 369

Fig. 3.6 Synoptic metamodel: interface this

figur

ew

illbe

prin

ted

inb/

w


Uncor

recte

d Proof

SPaCIFY Project

Fig. 3.7 Synoptic metamodel: model diagram

this

figur

ew

illbe

prin

ted

inb/

w

block, or an instance of block interface (see ModelInstance class in Fig. 3.7). 370In the latter case, the model is abstract: the designer must implement all the block 371interfaces used to type sub-blocks in order to obtain a concrete model. As such, 372Synoptic environment design promotes a top-down approach. 373

Automaton 374

An automaton block models state machines. A Synoptic automaton consists of 375states and transitions. As for dataflow, a state can be represented by an instance 376of dataflow, automaton or block interface. Dataflow diagrams and automata can be 377hierarchically nested; this allows for a compact modelling of operational modes. 378

Apart from the ongoing actions of automata (block embedded in state), it is 379possible to specify entry and exit actions in an imperative style. Transitions between 380states are guarded and equipped with actions. There are two types of transitions in 381Synoptic: strong and weak transitions. Strong transitions are used to compute the 382current state of the automaton (before entering the state), whereas weak transitions 383are used to compute the state for the next instant. 384

More precisely, the guards of weak transitions are evaluated to estimate the state 385for the next instant, and the guards of strong transitions whose source is the state 386estimated at the previous instant, are evaluated to determine the current state. 387

External Block 388

A common practice in software industry is the re-use of external source code: de- 389signers must be able to introduce blocks representing existing source code into the 390model. Moreover, for modeling flight software functional units, it is necessary to 391use primitive operations such as addition, cosinus, division. 392


Uncor

recte

d Proof


Synoptic provides the concept of external block to model primitive blocks and ex- 393ternal source code, Fig. 3.7. Primitive blocks are encapsulated in a Synoptic library. 394The Synoptic tool suit recognizes these primitive operations during code generation. 395

For embedding an external source code, the procedure is quite different. The 396designer must build his own external block by defining its interface, by giving the 397source code path which will be used at code generation time, and by specifying 398pre/post conditions and the Worst Case Execution Time of the functional unit. 399

Example: A Dataflow Block Diagram 400

Figure 3.8 shows the graphical decomposition of the nominal mode of the Atti- 401tude and Orbit Control System (AOCS/NM) depicted in (Fig. 3.5b). The header of 402the block tells us that NM is an instance of the NM dtf dataflow block. In nominal 403mode, AOCS can either use its sun pointing sensors (SUP) to define its position or, 404during eclipse, use its geocentric pointing sensors (GAP). To model this activity, 405the nominal mode of the AOCS flight software encapsulates two sub-blocks: one 406dataflow block (TEST ECLIPSE) which detects an eclipse occurrence and one au- 407tomaton block (SUP OR GAP) which ensures the change of sub-mode (SUP or GAP) 408depending on the outcome of the eclipse test block. 409

3.2.2.2 Synchronous Islands 410

A functional model consists of synchronous islands. A synchronous island is a 411synchronous functional unit in interaction with the middleware. The middleware 412supports the execution of code generated from the Synoptic model: it provides a 413synchronous abstraction of the asynchronous real world. 414

Fig. 3.8 AOCS nominal (NM) sub-mode – satellite positioning software

this

figur

ew

illbe

prin

ted

inb/

w


Uncor

recte

d Proof

SPaCIFY Project

To ensure proper integration of the generated code with the middleware platform, 415it is essential to locate all interactions between the middleware and the application. 416

Our approach is to locate all these interactions into a single concept in Synoptic: 417the concept of external variables. External variables allow to represent in Synop- 418tic models the following domain specific and technical concepts: telecommand, 419telemetry, constants database systems, shared variables and persistent variables (on 420reboot). The specification of external variables are used for code generation and 421middleware configuration. 422

Therefore a Synoptic synchronous island is a block in which all input and output 423signals are connected to external variables. The OBSW block of our case study is 424one such synchronous island, Fig. 3.5a. 425

Contractual Approach 426

An external variable is a variable managed by the middleware. It can be read or 427written by multiple clients (components of the application). Contracts are used to 428specify how to control this access. 429

The configuration of an external variable is done using four levels of contracts: 430

1. A classical syntactic contract that includes its name and type 4312. A remote access contract (through telemetry) 4323. A persistence contract that specifies if the variable is persistent on reboot or not 4334. A synchronization contract that describes the possible concurrent interactions 434

when the variable is shared 435

Each component using such a variable must also provide a usage contract that 436defines the protocol it will use to access the variable. 437

These contracts allow the middleware to manage the variable. Thus, the synchro- 438nization contract will indicate if locks are needed and when they should be used. 439The persistence contract will indicate how the variable should be stored (RAM or 440permanent memory). The monitoring functions of the variable that the middleware 441must implement are defined by the remote access contract and the usage contracts. 442

3.2.2.3 Control and Temporal Properties 443

As described before, blocks are functional units of compilation and execution. Block 444execution is controlled using two specific control ports: triggerand reset ports. These 445ports are inherited from the Simulink/Stateflow approach [4]. These ports appear as 446black triangles in the upper left of the block, Figs. 3.5 and 3.8. 447

Trigger Port 448

The trigger port is an event port. The occurrence of a trigger event starts the execu- 449tion of the block and its specification may then operate at its own pace until the next 450trigger is signaled. 451


Uncor

recte

d Proof


Sub-blocks have their own trigger control ports and can thus operate at a different 452rate. Without event signal connecting its control port, a sub-block inherits the control 453signals of its parent block. 454

Explicit Clock and Adaptors 455

The trigger port stands for the clock of the block. In our case study, the trigger con- 456trol port of blocks is never connected: the clock of the block is explicitly defined 457using a period or a frequency property. Adding this frequency property is semanti- 458cally equivalent to connecting the trigger control port with a 20-Hz clock. 459

By convention, all input signals of the block are synchronized with the trigger of 460the parent block. This constraint may be too strict: it is thus possible to redefine the 461frequency of ports by adding an explicit property of frequency. Note however that 462the clock of ports must be a down-sampling of the parent trigger. 463

Explicitly specifying a real-time constraint on ports and blocks can lead to 464difficulties when specifying a flow between two ports with different frequencies. 465Synoptic tools are able to detect such clock errors. The designer should use pre- 466defined clock adaptors to resample the signal, Fig. 3.8. 467

Besides frequency properties, it is possible to specify the phase and the Worst 468Case Execution Time (WCET) of a block. 469

Reset Port 470

The reset port is a boolean data port whose clock is a down-sampling of the trigger 471signal. The reset signal forces the block B to reset its state and variables to initial 472values. 473

Contrarily to StateCharts [24], when a transition is fired the destination state of 474the transition is not reset. It means that by default, one enters the history state. To 475reset the destination state and all variables it contains, the solution is to specify this 476reset in the action of the transition. 477

3.2.2.4 Properties Specification 478

The Synoptic language is equipped with an assertion language to state desired prop- 479erties of the model under development. This language makes it possible to express 480invariants, pre- and post-conditions on blocks. 481

Invariants are used to express coherence of modes. For instance, a typical asser- 482tion that we want to prove on the case study model (Fig. 3.5) is that if the MCS block 483is in SAFE mode, then the AOCS block is also in SAFE mode. Such an assertion is 484described in Synoptic as follows: 485

(OBSW.MCS.state = SAFE) H) (OBSW.AOCS.state = SAFE) 486


Uncor

recte

d Proof

SPaCIFY Project

The Synoptic environment provides a tool to extract Synoptic models and their 487associated properties and pass them to the Altarica model-checker [1]. 488

Pre- and post-conditions can be either statically or dynamically tested. In the 489latter case, monitoring functions are implemented in the final software and raise 490events when properties are not satisfied. 491

Monitoring functions are distinguished from assertion properties by raising an 492event to its environment when the property is not satisfied: 493

Assertion : pre : a < 10 ;Monitoring function : pre : a < 10 raise eŠ ;

494

Here, a stand for an input data port and e for an event port and eŠ for an event 495emission on e port. 496

3.2.3 Synoptic Components: Genericity and Modularity 497

Synoptic supports modular system development and parametric components. The 498latter are particularly useful for an incremental design and gradual refinement, using 499predefined development patterns (see Sect. 3.2.4). 500

As mentioned in Sect. 3.2.2.1, there are two main categories of compo- 501nents: dataflow blocks and automata blocks. They exist on the type level (interfaces) 502and on the element level (instances). Components can be parametric, in the sense 503that a block can take other elements as arguments. Parametric components are sim- 504ilar to functors in ML-style programming languages, but parameters are not limited 505to be blocks. They can, among others: 506

� Be integers, thus allowing for variable-sized arrays whose length is only fixed 507during compile time 508

� Be types, thus allowing for type genericity as in Java 5 [19] 509� Be entire components, thus allowing for component assembly from more ele- 510

mentary blocks 511

Syntactically, the parameters of a block are specified after a requires clause, 512the publicly visible elements made available by the block follow in a provides 513clause, and there maybe a private part, as in Fig. 3.9. 514

This example reveals parts of the textual syntax of Synoptic , which in this case 515is more perspicuous than a graphical syntax. The component C requires (an instance 516of ) a block, called ADD, that is characterized by a component type having a certain 517number of in and out ports. C provides a dataflow that is composed of two blocks, 518one of which is defined in the private part of C. 519

Parameterized blocks can be instantiated with elements that meet their typing 520constraints, in a large sense. In the case of simple parameter types (like integers), 521the typing constrains are evident. When instantiating a parameterized component 522having a parameter type P with a component C , the component C has to provide 523all the elements stipulated by the requires clause of P (but may provide more). 524


Uncor

recte

d Proof


this

figur

ew

illbe

prin

ted

inb/

w1 component C2 r e q u i r e s3 block type ADD4 f e a t u r e s5 idp1 : in data port i n t e g e r;6 idp2 : in data port i n t e g e r;7 odp1 : out data port i n t e g e r;8 end ADD;9 p r o v i d e s

10 data f low ADD_MULT.op11 b l o c k s12 add : block type ADD;13 mult : block type MULT;14 f l o w s15 s1 : data idp1! add.idp1;16 -- other flows ...17 end ADD_MULT.op;18 p r i v a t e19 block type MULT20 f e a t u r e s21 -- ...22 end MULT;23 end C;

Fig. 3.9 A parameterized component

Conversely, C may require some (but not necessarily all) the elements provided 525by P . Parameter instantiation is thus essentially contravariant. Some clauses of a 526component are not checked during instantiation, such as private. 527

Parameter types can be equipped with properties (see Sect. 3.2.2.4) such as 528temporal properties. Instantiating these types gives rise to proof obligations, de- 529pending on the underlying logic. In some cases, an exact match between the formal 530parameter component and the actual argument component is not required. In this 531case, a mechanism comparable to a type cast comes into play: Take, for example, 532the case of a component triggered at 20 Hz C20j (as in Fig. 3.8) that is to be used 533by a parametric component C10j operating at 10 Hz. Component C20j can be used 534as argument of C10j, and a default frequency splitter will be synthesized that adapts 535the frequency of the C20j to C10j. 536

3.2.4 Incremental Design and Refinement Features 537

The Synoptic environment promotes a top-down approach including incremental 538design and refinement features. 539


Uncor

recte

d Proof

SPaCIFY Project

Fig. 3.10 Synoptic metamodel: refinement

this

figur

ew

illbe

prin

ted

inb/

w

In first steps of design, Synoptic allows to describe an abstract model. For in- 540stance, the designer can describe abstract interfaces where data ports are not typed 541and connect instances of these interfaces in a dataflow diagram. 542

In a second step, the designer can refine its modeling by typing the block in- 543terfaces. The block interface can be then implemented with dataflow or automaton 544blocks. These features of the Synoptic environment are mainly “edition refinement” 545which allows the designer to model a system in an incremental way. In doing so, the 546designer loses the link between the different levels of refinement: when the model 547is concretized, the initial abstract model is not preserved and therefore cannot be 548accessed. 549

Synoptic offers a way to specify refinement and to keep a formal link between 550an abstract model and its concretization. As depicted in the metamodel, Synoptic 551provides two types of refinements: flow refinement and block refinement, Fig. 3.10. 552

A flow refinement consists of refining a flow with a dataflow block. To be properly 553defined, the flow must be declared as abstract and the dataflow block must have a 554single input port and a single output port correctly typed. 555

A block refinement consists of refining a block instance with a dataflow block. 556The main use of this type of refinement is to concretize an interface block with a 557dataflow. 558

Example 559

Figure 3.11 illustrates a flow refinement. The first model is an abstract view of the 560global architecture of the case study. 561

The abstract model consists of three dataflow blocks. Sensors send their data 562(position and attitude) to the central flight software. OBSW computes them and sends 563a new command to actuators. In this abstract block diagram, flows between actuators 564and the OBSW are obviously not synchronous signals: data are exchanged through 565an 1553 bus. 566


Uncor

recte

d Proof


Fig. 3.11 Flow refinement: introduce external variables

this

figur

ew

illbe

prin

ted

inb/

w

To consider this fact, flows are specified as abstract. The same applies to the 567flows between OBSW and actuators. Moreover, a real-time requirement is added to 568the flows:� delay � 20�s�. 569

This requirement represents the maximum age of data: data consumed by OBSW 570must be aged less than 20�s. The second model in Fig. 3.11 shows how this abstract 571model is refined. Each flow is refined with a dataflow block composed of external 572variables. 573

The concrete model confirms that data sent by the sensors are not Synchronous 574flows but pass through the middleware. According to the real-time requirement of 575abstract model, the middleware is in charge of distributing data to flight software 576by respecting the limit of data aging. In addition, this refinement step displays the 577OBSW synchronous island. 578

3.3 Semantic and Model of Computation of synoptic Models 579

The model of computation on which Synoptic relies is that of the Eclipse-based 580synchronous modeling environment SME [9]. SME is used to transform Synoptic 581diagrams and executable generate C code. The core of SME is based on the syn- 582chronous dataflow language SIGNAL [22]. This section describes how Synoptic 583programs are interpreted and compiled into this core language. 584

3.3.1 An Introduction to SIGNAL 585

In SIGNAL, a process P consists of the composition of simultaneous equations 586x D f .y; z/ over signals x; y; z. A delay equation x D y pre v defines x every 587time y is present. Initially, x is defined by the value v, and then, it is defined by the 588


Uncor

recte

d Proof

SPaCIFY Project

previous value of y. A sampling equation x D y when z defines x by y when z is 589true. Finally, a merge equation x D y default z defines x by y when y is present 590and by z otherwise. An equation x D yfz can use a boolean or arithmetic operator 591f to define all of the nth values of the signal x by the result of the application of f 592to the nth values of the signals y and z. The synchronous composition of processes 593P jjQ consists of the simultaneous solution of the equations in P and in Q. It is 594commutative and associative. The process P=x restricts the signal x to the lexical 595scope of P . 596

P;Q WWD x D yfz j P=x j P jjQ (process):

In SIGNAL, the presence of a value along a signal x is an expression noted Ox. It is 597true when x is present. Otherwise, it is false. Specific processes and operators are 598defined in SIGNAL to manipulate clocks explicitly. We only use the simplest one, 599x sync y, that synchronizes all occurrences of the signals x and y. 600

3.3.2 Interpretation of Blocks 601

Blocks are the main structuring elements of Synoptic. A block block xA defines a 602functional unit of compilation and of execution that can be called from many con- 603texts and with different modes in the system under design. A block x encapsulates a 604functionality A that may consist of sub-blocks, automata and dataflows. A block x 605is implicity associated with two signals x:trigger and x:reset. The signal x:trigger 606starts the execution of A. The specification A may then operate at its own pace until 607the next x:trigger is signaled. The signal x:reset is delivered to x at some x:trigger 608and forces A to reset its state and variables to initial values. 609

.blocks/ A;B WWD block xA j dataflow xA j automaton xA j A jjB :

The execution of a block is driven by the trigger t of its parent block. The block 610resynchronizes with that trigger when itself or one of its sub-blocks makes an ex- 611plicit reference to time (e.g., a skip for an action or a delayed transition S � T 612for an automaton). Otherwise, the elapse of time is sensed from outside the block, 613whose operations (e.g., on ci ), are perceived as belonging to the same period as 614within Œti ; tiC1Œ. The interpretation implements this feature by encoding actions and 615automata using static single assignment. As a result, and from within a block, ev- 616ery non-time-consuming sequence of actions AIB or transitions A ! B defines 617the value of all its variables once and defines intermediate ones in the flow of its 618execution. 619

3.3.3 Interpretation of Dataflow 620

Dataflows inter-connect blocks with data and events (e.g., trigger and reset signals). 621A flow can simply define a connection from an event x to an event y, written 622


Uncor

recte

d Proof


event x ! y, combine data y and z by a simple operation f to form the flow 623x, written data y f z! x or feed a signal y back to x, written data y pre v! x. 624In a feedback loop, the signal x is initially defined by x0 D v. Then, at each 625occurrence n > 0 of the signal y, it takes its previous value xn D yn�1. The 626execution of a dataflow is controlled by its parent clock. A dataflow simultaneously 627executes each connection it is composed of every time it is triggered by its parent 628block. 629

.dataflow/ A;B WWD data y pre v! x j data yfz! x j event x ! y j A jjB :

Dataflows are structurally similar to SIGNAL programs and equally combined 630using synchronous composition. The interpretation ŒŒA��rt D hhP ii of a dataflow 631(Fig. 3.12) is parameterized by the reset and trigger signals of the parent block and 632returns a process P (The input term A and the output term P are marked by ŒŒA�� 633and hhP ii for convenience). A delayed flow data y pre v! x initially defines x by 634the value v. It is reset to that value every time the reset signal r occurs. Otherwise, 635it takes the previous value of y in time. 636

In Fig. 3.12, we writeQi�n Pi for a finite product of processes P1jj : : : Pn. Sim- 637

ilarly,Wi�n ei is a finite merge of signals e1 default : : : en and

Vi�n ei a finite 638

sampling e1 when : : : en. 639A functional flow data yfz ! x defines x by applying f to the values of y 640

and z. An event flow event y ! x connects y to define x. Particular cases are the 641operator ‹.y/ to convert an event y to a boolean data and the operator O.y/ to convert 642the boolean data y to an event. We write in.A/ and out.A/ for the input and output 643signals of a dataflow A. 644

By default, the convention of Synoptic is to synchronize the input signals of a 645dataflow to the parent trigger. It is however, possible to define alternative policies. 646One is to down-sample the input signals at the pace of the trigger. Another is to adapt 647or resample them at that trigger. Alternatively, adaptors could better be installed 648around the input and output signals of a block in order to resample them with respect 649to the specified frequency of the block. 650

ŒŒdataflow f A��rt DhhŒŒA��rt jj�Q

x2in.A/ x sync t�ii

ŒŒ data y pre v! x��rt Dhhx D .v when r/ default .y pre v/ jj .x sync y/ii

ŒŒ data y f z! x��rt Dhhx D y f ziiŒŒ event y ! x��rt Dhhx D whenyii

ŒŒA jjB��rt DhhŒŒA��rt jj ŒŒB��rt ii

Fig. 3.12 Interpretation of dataflow connections


Uncor

recte

d Proof

SPaCIFY Project

3.3.4 Interpretation of Actions 651

Actions are sequences of operations on variables that are performed during the exe- 652cution of automata. 653

The assignment x D yfz defines the value of the variable x at the next instant 654as the result of the application of the function f to y and z. The skip action lets 655time elapse until the next trigger and assigns to unchanged variables the value they 656had at the previous instant. The conditional if x thenA elseB executes A if the cur- 657rent value of x is true and executes B otherwise. A sequence AIB executes A and 658then B . 659

.action/ A;B WWD skip j x D yfz j if x thenA elseB j AIB :

The execution of an action A starts at an occurrence of its parent trigger and 660shall end before the next occurrence of that event. During the execution of an action, 661one may also wait and synchronize with this event by issuing a skip: A skip has 662no behavior but to signal the end of an instant: all the newly computed values of 663signals are flushed in memory and execution is resumed upon the next parent trigger. 664Action xŠ sends the signal x to its environment. Execution may continue within the 665same symbolic instant unless a second emission is performed: one shall issue a skip 666before that. An operation x D yfz takes the current value of y and z to define the 667new value of x by the product with f . A conditional if x thenA elseB executes A 668or B depending on the current value of x. 669

As a result, only one new value of a variable x should at most be defined within 670an instant delimited by a start and an end or a skip. Therefore, the interpretation of an 671action consists of its decomposition in static single assignment form. To this end, we 672use an environment E to associate each variable with its definition, an expression, 673and a guard, that locates it (in time). 674

An action holds an internal state s that stores an integer n denoting the current 675portion of the actions that is being executed. State 0 represents the start of the pro- 676gram and each n > 0 labels a skip that materializes a synchronized sequence of 677actions. 678

The interpretation ŒŒA��s;m;g;E D hhP iin;h;F of an action A (Fig. 3.13) takes as 679parameters the state variable s, the state m of the current section, the guard g that 680leads to it, and the environment E. It returns a process P , the state n and guard h of 681its continuation, and an updated environment F . The set of variables defined in E 682is written V .E/. We write usegE .x/ for the expression that returns the definition of 683the variable x at the guard g and defgE .x/ for storing the final values of all variables 684x defined in E at the guard g. 685

usegE .x/D if x 2 V .E/ then hhE.x/ii else hh.x pre 0/when gii;

defg.E/DQx2V .E/

�x D usegE .x/

�:


Uncor

recte

d Proof


ŒŒ doA��rt Dhh.P jj s sync t jj rD.sD0// =siiwhere hhP iin;h;FDŒŒAI end ��s;0;..spre0/D0/;;

ŒŒ end ��s;n;g;E DhhsD0when g jj defg.E/ii0;0;;ŒŒ skip ��s;n;g;E DhhsDnC 1wheng jj defg.E/iinC1;..spre0/DnC1/;;ŒŒxŠ��s;n;g;E DhhxD1when giin;g;E

ŒŒxDyfz��s;n;g;E DhhxDeiin;g;Ex]fx 7!eg where eDhhf .usegE .y/; usegE .z//whengii

ŒŒAIB��s;n;g;E DhhP jjQiinB ;gB ;EB where hhP iinA;gA;EADŒŒA��s;n;g;E and

hhQiinB ;gB ;EBD ŒŒB��s;nA;gA;EA

ŒŒ if x then A else B��s;n;g;E DhhP jjQiinB ;.gA defaultgB /;.EA]EB /

where hhP iinA;gA;EA D ŒŒA��s;n;.gwhen useg

E.x//;E and hhQiinB ;gB ;EBDŒŒB��

s;nA;.gwhennot usegE.x//;E

Fig. 3.13 Interpretation of timed sequential actions

Execution is started with s D 0 upon receipt of a trigger t . It is also resumed from 686a skip at s D n with a trigger t . Hence the signal t is synchronized to the state s of 687the action. The signal r is used to inform the parent block (an automaton) that the 688execution of the action has finished (it is back to its initial state 0). An end resets s 689to 0, stores all variables x defined in E with an equation x D usegE .x/ and finally 690stops (its returned guard is 0). A skip advances s to the next label n C 1 when it 691receives control upon the guard e and flushes the variables defined so far. It returns 692a new guard .s pre 0/ D n C 1 to resume the actions past it. An action xŠ emits x 693when its guard e is true. A sequenceAIB evaluatesA to the processP and passes its 694state nA, guard gA, environment EA to B . It returns P jjQ with the state, guard and 695environment of B . Similarly, a conditional evaluates A with the guard gwhen x to 696P and B with gwhen not x toQ. It returns P jjQ but with the guard gA defaultgB . 697All variables x 2 X , defined in both EA and EB , are merged in the environment F . 698

In Fig. 3.13, we write E ] F to merge the definitions in the environments E and 699F . For all variables x 2 V .E/ [ V .F / in the domains of E and F , 700

.E ] F /.x/ D

8<

:

E.x/; x 2 V .E/ n V .F /;

F.x/; x 2 V .F / n V .E/;

E.x/ defaultF.x/; x 2 V .E/ \ V .F /:

Note that an action cannot be reset from the parent clock because it is not synchro- 701nized to it. A sequence of emissions xŠI xŠ yield only one event along the signal 702x because they occur at the same (logical) time, as opposed to xŠI skip I xŠ which 703sends the second one during the next trigger. 704


Uncor

recte

d Proof

SPaCIFY Project

0 x1 D 0I

1 ify

2 then x2 D x1 C 1

3 else f

4 x3 D x1 � 1I

5 x D x3I

6 skip I

7 x4 D x � 1

8 gI

9 x D �.x2; x4/

10 end

x1D0when .sD0/

x2Dx1 C 1when .sD0/when y

x3Dx1 � 1when .sD0/when noty

x4D.x pre 0/ � 1when .sD1/

xD x2 when .sD0/when y

default x3 when .sD0/when noty

default x4 when .sD1/

s0D 0when .sD1/

default 0when .sD0/when y

default 1when .sD0/when noty

sDs0 pre 0

Fig. 3.14 Tracing the interpretation of a timed sequential program

Example 705

Consider the simple sequential program of the introduction. Its static single assign- 706ment form is depicted in Fig. 3.14. 707

x D 0I ify then fx D x C 1g else fx D x � 1I skip I x D x � 1gI end

As in GCC, it uses a �-node, line 9 to merge the possible values x2 and x4 of xAQ4 708flowing from each branch of the if . 709

Our interpretation implements this � by a default equation that merges these two 710values with the third, x3, that is stored into x just before the skip line 6. The in- 711terpretation of all assignment instructions in the program follows the same pattern.1 712Line 2, for instance, the value of x is x1, which flows from line 1. Its assignment to 713the new definition of x, namely x2, is conditioned by the guard y on the path from 714line 1 to 2. It is conditioned by the current state of the program, which needs to be 7150, from line 1 to 6 and 9 (state 1 flows from line 7 to 9, overlapping on the �-node). 716Hence the equation x2 D x1 C 1when .sD0/when y. 717

3.3.5 Interpretation of Automata 718

Automata schedule the execution of operations and blocks by performing timely 719guarded transitions. An automaton receives control from its trigger and reset signals 720

1 In the actual translation, temporary names x1;:::;5 are substituted by the expression that definesthem. We kept them in the figure for a matter of clarity.


Uncor

recte

d Proof


x:trigger and x:reset as specified by its parent block. When an automaton is first 721triggered, or when it is reset, its starts execution from its initial state, specified as 722initial stateS . On any state S W doA, it performs the action A. From this state, 723it may perform an immediate transition to new state T , written S !on x T , if 724the value of the current variable x is true. It may also perform a delayed transition 725to T , written S �on x T , that waits the next trigger before to resume execution 726(in state T ). If no transition condition applies, it then waits the next trigger and 727resumes execution in state S . States and transitions are composed as A jjB . The 728timed execution of an automaton combines the behavior of an action or a dataflow. 729The execution of a delayed transition or of a stutter is controlled by an occurrence of 730the parent trigger signal (as for a dataflow). The execution of an immediate transition 731is performed without waiting for a trigger or a reset (as for an action). 732

.automaton/ A;B WWD stateSW doA j S !on x T j S �on x T j A jjB :

An automaton describes a hierarchic structure consisting of actions that are ex- 733ecuted upon entry in a state by immediate and delayed transitions. An immediate 734transition occurs during the period of time allocated to a trigger. Hence, it does not 735synchronize to it. Conversely, a delayed transition occurs upon synchronization with 736the next occurrence of the parent trigger event. As a result, an automaton is parti- 737tioned in regions. Each region corresponds to the amount of calculation that can be 738performed within the period of a trigger, starting from a given initial state. 739

Notations 740

We write !A and �A for the immediate and delayed transition relations of an 741automaton A. We write pred!A.S/ D fT j .T; x; S/ 2 Rg and succ!A.S/ D 742fT j .S; x; T / 2 Rg (resp. pred�A

.S/ and succ�A.S/) for the predecessor and 743

successor states of the immediate (resp. delayed) transitions!A (resp. �A) from 744a state S in an automaton A. Finally, we write S for the region of a state S . It is 745defined by an equivalence relation. 746

8S; T 2 S .A/; ..S; x; T / 2 !A/, S D T:

For any state S of A, written S 2 S .A/, it is required that the restriction of!A to 747the region S is acyclic. Notice that, still, a delayed transition may take place between 748two states of the same region. 749

Interpretation 750

An automaton A is interpreted by a process ŒŒ automaton x A��rt parameterized by 751its parent trigger and reset signals. The interpretation of A defines a local state s. It 752is synchronized to the parent trigger t . It is set to 0, the initial state, upon receipt of 753


Uncor

recte

d Proof

SPaCIFY Project

a reset signal r and, otherwise, takes the previous value of s0, that denotes the next 754state. The interpretation of all states is performed concurrently. 755

We give all states Si of an automaton A a unique integer label i D dSie and 756designate with dAe its number of states. S0 is the initial state and, for each state 757of index i , we call Ai its action i and xij the guard of an immediate or delayed 758transition from Si to Sj . 759

ŒŒ automaton x A��rt D

hh�t sync s jj s D .0when r/ default .s0 pre 0/ jj

�QSi2S .A/ ŒŒSi ��

s��=ss0ii :

The interpretation ŒŒSi ��s of all states 0 � i < dAe of an automaton (Fig. 3.15) is 760implemented by a series of mutually recursive equations that define the meaning of 761each state Si depending on the result obtained for its predecessors Sj in the same 762region. Since a region is by definition acyclic, this system of equations has therefore 763a unique solution. 764

The interpretation of state Si starts with that of its actions Ai . An action Ai 765defines a local state si synchronized to the parent state s D i of the automaton. The 766automaton stutters with s0 D s if the evaluation of the action is not finished: it is in 767a local state si ¤ 0. 768

Interpreting the actions Ai requires the definition of a guard gi and of an envi- 769ronment Ei . The guard gi defines when Ai starts. It requires the local state to be 0 770or the state Si to receive control from a predecessor Sj in the same region (with the 771guard xj i ). 772

The environment Ei is constructed by merging these Fj returned by its imme- 773diate predecessors Sj . Once these parameters are defined, the interpretation of Ai 774returns a process Pi together with an exit guard hi and an environment Fi holding 775the value of all variables it defines. 776

8i < dAe; ŒŒSi ��s D

�Pi jjQi jj si sync when .s D i/ jj s0 D s0i

�=si where

hhPi iin;hi ;Fi D ŒŒAi ��si ;0;gi ;Ei

Qi DQ.Si ;xij ;Sj /2�A

�defhi when .useFi .xij //

.Fi /�

Ei DUSj2pred

!A.Si /

Fj

gi D 1when .si pre 0 D 0/ default�W

.Sj ;xji ;Si /2!A.useE .xj i //

�

gij D hi when .useFi .xij //; 8.Si ; xij ; Sj / 2�A

s0i D .s when si ¤ 0/ default�W

.Si ;xij ;Sj /2�A.j whengij /

�

Fig. 3.15 Recursive interpretation of a mode automaton


Uncor

recte

d Proof


Upon evaluation of Ai , delayed transition from Si are checked. This is done by 777the definition of a process Qi which, first, checks if the guard xij of a delayed 778transition from Si evaluates to true with Fi . If so, variables defined in Fi are stored 779with defhi .Fi /. 780

All delayed transitions from Si to Sj are guarded by hi (one must have finished 781evaluating i before moving to j ) and a condition gij , defined by the value of the 782guard xij . The default condition is to stay in the current state s while si ¤ 0 (i.e., 783until mode i is terminated). 784

Hence, the next state from i is defined by the equation s0 D s0i . The next state 785equation of each state is composed with the other to form the product

Qi<dAe s

0Ds0i 786that is merged as s0 D

Wi<dAe s

0i . 787

Example 788

Reconsider our previous sequential program, which we now represent by a mode au- 789tomaton (Fig. 3.16, left). Our interpretation of automata merges, loads and stores the 790variables defined in states S1:::5. Thanks to a decomposition in regions, this provides 791an interpretation with synchronous equations that has an equivalent meaning as that 792of a sequential program. 793

One can actually check that the translation of the automaton (Fig. 3.16, right) 794is identical to that of the original program modulo substitution of local the local 795signals x1;:::;4 by their definition. 796

3.3.6 The Polychronous Model of Computation 797

The polychronous model of computation [22] defines the algebra in which the de- 798notational semantics of Signal is expressed. In this algebra, symbolic tags t or u 799denote periods in time during which execution takes place. Time is defined by a 800

S0 W do x D 0

jj S0 !ony S1

jj S0 !on noty S2

S1 W do x D x C 1 jjS1 ! S5S2 W do x D x � 1 jjS2 � S4S4 W do x D x � 1 jjS4 ! S5S5 W end

x D 0 � 1when .s D 0/when noty

default 0C 1when .s D 0/when y

default .x pre 0/ � 1when .s D 1/

jj s0 D 1when .s D 0/when not y

default 0when .s D 0/when y

default 0when .s D 1/

jj s D s0 pre 0

Fig. 3.16 SSA interpretation of a mode automaton into dataflow equations


Uncor

recte

d Proof

SPaCIFY Project

partial order relation� on tags: t � u stipulates that t occurs before u or at the same 801time. A chain is a totally ordered set of tags. It corresponds to the clock of a signal: 802it samples its values over a series of totally related tags. The domains for events, 803signals, behaviors and processes are defined as follows: 804

– An event is a pair consisting of a tag t 2 T and a value v 2 V . 805– A signal s 2 S is a function from a chain of tags C � T to a set of values 806

v 2 V . 807– A behavior b 2 B is a function from a set of names X � V to signals. 808– A process p 2P is a set of behaviors that have the same domain. 809

Notations 810

We write T .s/ for the chain of tags of a signal s and min s and max s for its minimal 811and maximal tag. We write V .b/ for the domain of a behavior b (a set of signal 812names). The restriction of a behavior b to X is noted bjX (i.e., V .bjX / D X ). 813Its complementary b=X satisfies b D bjX ] b=X (i.e., V .b=X / D V .b/ n X ). We 814overload T and V to designate the tags of a behavior b and the set of signal names 815of a process p. Since tags along a signal s form a chain C D T .s/, we write Ci for 816the i th instant in chain C and have that Ci � Cj iff i � j for all i; j � 0. 817

Reaction 818

A reaction r is a behavior with (at most) one time tag t . We write T .r/ for the tag of 819a non empty reaction r . A reaction r is concatenable to a behavior b, written b �‹ r , 820iff r and b have the same domain V .b/ D V .c/ and if max.T .b// < min.T .c//. 821The concatenation of r to b is written b � r and defined by .b � c/.x/ D b.x/] r.x/ 822for all x 2 V .b/. 823

Synchronous Structure 824

A behavior c is a stretching of a behavior b, written b � c, iff V .b/ D V .c/ and 825there exists a bijection f on tags s.t. 826

8t; u; t � f .t/ ^ .t < u, f .t/ < f .u//; 8278x 2 V .b/;T .c.x// D f .T .b.x/// ^ 8t 2 T .b.x//; b.x/.t/ D c.x/.f .t//: 828

b and c are clock-equivalent, written b c, iff there exists a behavior d s.t. d � b 829and d � c. The synchronous composition p jj q of two processes p and q is defined 830by combining behaviors b 2 p and c 2 q that are identical on the interface between 831p and q: I D V .p/ \ V .q/. 832

p jj q D fb [ c j .b; c/ 2 p q ^ bjI D cjI ^ I D V .p/ \ V .q/g :


Uncor

recte

d Proof


Alternatively, the synchronous structure of a process can be interpreted as an 833equivalence relation that refines the causal tag structure of individual signals 834(for all b 2 B, for all x 2 V .b/, T .b.x// is a chain of T ). If we make the as- 835sumption that the only phenomenological structure is this causal structure, then the 836synchronous structure of a behavior b can be seen as a way to slice time across 837individual signals in a way that preserves causality: for all t; u 2 T .b/, 1. t < u iff 838t 6b u and 2. t � u iff t u or t < v and v b u. 839

Denotation of Data-Flow Diagrams 840

A data-flow dataflowf A is defined by the meaning of A controlled by the parent 841timing C . A delayed flow data yfz! x assigns v to the signal x upon reset t 2 C r 842and the previous value of y otherwise, at time predCx .t/. An operation data yfz! 843x assigns the product of the values u and v of y and z by the operation f to the 844signal x. An event event x ! y triggers x every time y occurs. Composition A jjB 845merges all timely compatible traces of A and B under the same context. 846

ŒŒdataflowf A��C D fb 2 ŒŒA��C j 8x 2 in.A/C t D T .b.x//g;

ŒŒ data y pre v! x��C D

8ˆˆ<

ˆˆ:

b 2 Bjx;y

ˇˇˇˇˇˇˇˇˇˇˇ

Cx D T .b.x// D T .b.y// � C v

C v D Cr [ fmin.T .b.x///g

8t 2 C v; b.x/.t/ D v

8t 2 Cx n C v; b.x/.t/ D b.y/.predCx .t//

9>>>>>=

>>>>>;

;

ŒŒ data yfz! x��C D

(

b 2 Bjx;y;z

ˇˇˇˇˇ

8t 2 T .b.x// D T .b.y// D T .b.z//;

b.x/.t/ D f .b.y/.t/; b.z/.t//

)

;

ŒŒ event y ! x��C D˚b 2 Bjx;y jT .b.x// D T .b.y//

�;

ŒŒA jjB��C D ŒŒA��C jj ŒŒB��C :

Denotation of Actions 847

Given its state b, the execution ck D ŒŒA��b of an action A returns a new state c and 848a status k whose value is 1 if a skip occurred and 0 otherwise. We write b#x D 849b.x/.min T .b// and b"x D b.x/.max T .b// for the first and last value of x in b. 850

A sequence first evaluates A to ck and then evaluates B with store b � c to dl . If 851k is true, then a skip has occurred in A, meaning that c and d belong to different 852instants. In this case, the concatenation of b and c is returned. 853

If k is false, then the execution that ended inA continues inB at the same instant. 854Hence, variables defined in the last reaction of c must be merged to variables defined 855in the first reaction of d . To this end, we write .b ‰ c/.x/ D b.x/ ] c.x/ for all 856x 2 V .b/ if t D max.T .b// D min.T .c//. 857


Uncor

recte

d Proof

SPaCIFY Project

ŒŒ doA��b D b � c ; where ck D ŒŒA��b;

ŒŒ skip ��b D ;1;

ŒŒxŠ��b D f.x; t; 1/g0;

ŒŒx D yfz��b D f�.x; t; f .b"y ; b"z/

�g0;

ŒŒ if x thenA elseB��b D if b"x then hhAiib else hhBiib;

ŒŒAIB��b D if k then .c � d/l else .c ‰ d/l ; where ck D ŒŒA��band dl D ŒŒB��b�c :

Denotation of Automata 858

An automaton x receives control from its trigger at the clock C t and is reset at the 859clock C r . Its meaning is hence parameterized by C D .C t ; C r /. The meaning of its 860specifications hhAiis

bis parameterized by the finite trace b, that represents the store, 861

by the variable s, that represents the current state of the automaton. 862At the i th step of execution, given that it is in state j (.bi /"s D j ) the automaton 863

produces a finite behavior biC1 D hhSj iisb . This behavior must match the timeline 864of the trigger: T .bi / � C t . It must to the initial state 0 is a reset occurs: 8t 2 865C r ; bi .s/.t/ D 0. 866

ŒŒ automaton x A��C D8<

:.ıi�0bi / =s

ˇˇˇˇˇˇˇ

b0 D f.x; t0; 0/ j x 2 V .A/ [ fsgg

8i � 0; biC1 2 ŒŒSj ��sbi;T .biC1/ � C

t

j D if min.T .biC1// 2 Cr then 0 else .bi /"s

9>=

>;

:

When an automaton is in the state Si , its action Ai is evaluated to c 2 hhAi iib given 867the store b. Then, immediate or delayed transitions departing from Si are evaluated 868to return the final state d of the automaton. 869

ŒŒSi ��sb D

8ˆ<

ˆ:

ŒŒSj ��sc ; .Si ; xij ; Sj / 2 !A ^ c"xij ;

c ] f.s; t; j /g; .Si ; xij ; Sj / 2�A ^ c"xij ; where c=s D ŒŒ doAi ��band t D max T c;

c ] f.s; t; i/g; otherwise:

3.4 Middleware Aspect 870

In order to support the execution of code generated from Synoptic model at runtime, 871a middleware is embedded in the satellite. This SPaCIFY middleware not only im- 872plements common middleware services such as communication or naming, but also 873offers domain-specific services of satellite flight control software. There are then 874


Uncor

recte

d Proof


two difficulties that must be addressed. First, one has take into account the scarce- 875ness of resources in a satellite. The large variety2 of satellite platforms from one 876project to another being the second. 877

To take into account the scarceness of resources in a satellite, this middleware is 878tailored to the domain and adapted to each specific project. This notion of generative 879middleware is inherited from the ASSERT project which has studied proof-based 880engineering of real-time applications but is here specialised to the area of satel- 881lite software. ASSERT defines a so-called virtual machine, which denotes a RTOS 882kernel along with a middleware and provides a language-neutral semantics of the 883Ravenscar profile [14]. It relies on PolyORB-HI [25], a high integrity version of 884PolyORB refining the broker design pattern [15], which fosters the reuse of large 885chunks of code when implementing multiple middleware personalities. Satisfying 886restrictions from the Ravenscar profile, PolyORB-HI can suitably be used as a run- 887time support for applications built with AADL code generators. In our context, the 888support of a precise adaptation to the need of the middleware is obtained thanks to 889its generation based on the requirements expressed in the Synoptic models (mainly 890through the interaction contracts attached to external variables). 891

Some of the services of the middleware cannot be reused and must be reimple- 892mented for each satellite. For example, the AOCS3 implements control laws that are 893specific to the expected flight and to the mission. Providing a framework, the mid- 894dleware will help capitalizing on the experience of domain expert, giving a general 895architecture for the AOCS. The models of services can belong to either the middle- 896ware or the application. In the later case, we use the same process as for the rest of 897the application, including the Synoptic language. Furthermore as services will have 898a well defined interface (i.e., an API) other services or applications using AOCS are 899not coupled to any particular implementation. 900

This section starts by presenting the architecture of the SPaCIFY middleware. 901Then, the middleware kernel and the communication between applications gener- 902ated from Synoptic models and their hosting middleware is explained. Lastly, the 903reconfiguration service that has been one of the main focus during the project is 904described. 905

3.4.1 Architecture of the Execution Platform 906

Figure 3.17 depicts the overall architecture of the SPaCIFY middleware. Following 907previous work on middlewares for real-time embedded systems [8,32], the SPaCIFY 908middleware has a microkernel-like or service-based architecture. That way, high 909flexibility allows to embed only the services that are required, depending on the 910

2 This diversity is due to the high specialisation of platforms for a specific mission and the broadrange of missions.3 Attitude and Orbit Control System.


Uncor

recte

d Proof

SPaCIFY Project

RTOSkernel

abstraction of the RTO

S

-m

id

dleware kernel -

synchronous islands

asynchronousenvironment

External variables

Management of external variables

bus & devices

on board/gound link

persistent memory

naming, time, persistency,reconfiguration,

redundancy, PUS TM/TC,PUS event, AOCS...

Services

Fig. 3.17 Architecture of the middleware

satellite. While previous work has focused on techniques to reduce the time during 911which the reconfigured system is suspended, along with an analysis to bound that 912time, our work aims at: 913

� Using application model to specify reconfiguration 914� Proposing a contract approach to the specification of relation between applica- 915

tions and the middleware 916� Providing on demand generation of the needed subset of the middleware for a 917

given satellite 918

The RTOS kernel offers the usual basic services such as task management and 919synchronisation primitives. The core middleware is built on top of this RTOS and 920provides core services of composition and communication. They are not intended 921to be used by application-level software. They rather provide means to structure the 922middleware itself in smaller composable entities, the services. Upon these abstrac- 923tions are built general purpose services and domain specific services. These services 924are to be used (indirectly) by the application software (here the various synchronous 925islands). They can be organized in two categories as follows: 926

� The first layer is composed of general purpose services that may be found in 927usual middleware. Among them, the naming service implements a namespace 928that would be suitable for distributed systems. The persistency service provides 929a persistent storage for keeping data across system reboots. The redundancy 930service helps increasing system reliability thanks to transparent replication man- 931agement. The reconfiguration service, further described in a dedicated subsection 932below (Sect. 3.4.3), adds flexibility to the system as it allows to modify the soft- 933ware at runtime. The task and event service contributes real-time dispatching of 934processors according to the underlying RTOS scheduler. It provides skeletons for 935


Uncor

recte

d Proof


various kinds of tasks, including periodic, sporadic and aperiodic event-triggered 936tasks, possibly implementing sporadic servers or similar techniques [26, 33]. 937

� The second layer contains domain-specific services to capture the expertise in the 938area of satellite flight control software. These services are often built following 939industry standards such as PUS [17]. The TM/TC service implements the well 940established telemetry/telecommand link with ground stations or other satellites. 941The AOCS (attitude and orbit control system) controls actuators in order to en- 942sure the proper positioning of the satellite. As discussed earlier, services may be 943implemented by synchronous islands. 944

To support the execution the platform use hardware resources provided by the 945satellite. As the hardware platform changes from one satellite to another, it must 946be abstracted even for the middleware services. Only the implementation of spe- 947cific drivers must be done for each hardware architecture. During the software 948development lifecycle, the appropriate corresponding service implementations are 949configured and adapted to the provided hardware. 950

As already exposed, one particularity of the SPaCIFY approach is the use of 951the synchronous paradigm. To support the use of the middleware services within 952this approach, we propose to use an abstraction, the external variable as shown in 953Sect. 3.2.2.2. Such a variable abstracts the interaction between synchronous islands 954or between a synchronous island and the middleware relaxing the requirements of 955synchrony. In the model, when the software architect wants to use a middleware 956service, he provides a contract describing its requirements on the corresponding 957set of external variables and the middleware is in charge to meet these require- 958ments. Clearly, this mediation layer in charge of the external variables management 959is specific to each satellite. Hence the contractual approach drives the generation of 960the proper management code. This layer is made of backends that capture all the 961asynchronous concerns such as accessing to a device or any aperiodic task, hence 962implementing asynchronous communications of the GALS approach. The middle- 963ware is in charge of the orchestration of the exchange between external variables, 964their managing backends and the services while ensuring the respect of quality of 965service constraints (such temporal one) specified in their contracts. 966

3.4.2 The Middleware Kernel and External Variables 967

As stated above, the middleware is built around a RTOS providing tasks and 968synchronisation. As the RTOS cannot be fixed due to industrial constraints, the 969middleware kernel must provide a common abstraction. It therefore embeds its own 970notion of task and for specific RTOS an adaptor must be provided. The implemen- 971tation of such adaptors has been left for future until now. Notice that the use of 972this common abstraction forbids the use of specific and sophisticated services of- 973fered by some RTOS. The approach here is more to adapt the services offered by 974the middleware to the business needs rather using low level and high performance 975services. 976


Uncor

recte

d Proof

SPaCIFY Project

The task is the unit of execution. Each task can contain Synoptic components 977according to the specification of the dynamic architecture of the application. Tasks 978have temporal features (processor provisioning, deadline, activation period) inher- 979ited from the Synoptic model. The middleware kernel is in charge of their execution 980and their monitoring. It is also in charge of provisioning resources for the aperiodic 981and sporadic tasks. 982

Communication inside a task results from the compilation of the synchronous 983specification of the various components it must support. All communication outside 984a task must go through external variables limiting interaction to only one abstraction. 985External variables are decomposed into two sub abstractions: 986

� The frontend identified in the Synoptic model and that constitutes the interaction 987point. It appears as a usual signal in the synchronous model and may be used as 988input or output. The way it is provided or consumed is abstracted in a contract 989that specify the requirements on the signal (such as its timing constraints). An 990external variable is said to be asynchronous because no clock constraint is intro- 991duced between the producer of the signal and its consumer. In the code generated 992access to such variables are compiled into getter and setter function implemented 993by the middleware. The contract must include usage requirements specifying the 994way the signal is used by the task (either an input or an output). They may also 995embed requirements on the freshness of the value or on event notifying value 996change. 997

� The backend specified using stereotypes in the contract configure the middle- 998ware behavior for non synchronous concerns. For example, persistency contract 999specify that the external variable must be saved in a persistent memory. Acquisi- 1000tion contracts can be used by a task to specify which data it must get before its 1001execution. Such backends are collected and global acquisition plan are built and 1002executed by the middleware. 1003

As the middleware supports the reconfiguration of applications at runtime, tasks 1004can be dynamically created. The dynamic modification of the features is also pro- 1005vided by the middleware. The middleware will have to ensure that these constraints 1006are respected. Beware that any modification must be made on the model and vali- 1007dated by the SPaCIFY tools to only introduce viable constraints. Each task has a miss 1008handler defined. This defensive feature makes the middleware execute corrective 1009actions and report an error whenever the task does not respect its deadline. 1010

3.4.3 Reconfiguration Service 1011

Among, domain specific services offered by the middleware, the reconfiguration 1012service is the one that had the most impact on the middleware conception. 1013

The design of the reconfiguration service embedded in the SPaCIFY middleware 1014is driven by the specific requirements of satellite onboard software. Reconfigura- 1015tion is typically controlled from ground stations via telemetry and telecommands. 1016


Uncor

recte

d Proof


Developer

offline

onboard softwaremodel

Operator ground station

OBSW imagecompilation

satellite state

abstractreconf plan

compilationaccording to theOBSW image

ground-satellite link

concretereconf plan

Fig. 3.18 Process and responsibilities for reconfigurations

Human operators not only design reconfigurations, they also decide the right time at 1017which reconfigurations should occur, for instance while the mission is idle. Due to 1018resource shortage in satellites, the reconfiguration service must be memory saving 1019in the choice of embedded metadata. Last, in families of satellites, software versions 1020tend to diverge as workarounds for hardware damages are installed. Nevertheless, 1021some reconfigurations should still apply well to a whole family despite the possible 1022differences between the deployed software. 1023

In order to tackle these challenges, the reconfiguration service rely on the struc- 1024tural model (Synoptic models) of the OBSW enriched by the current state of the 1025satellite as described in Fig. 3.18. Using the structure of the software allows to 1026abstract the low-level implementation details when performing reconfigurations. 1027While designing reconfigurations, operators can work on models of the software, 1028close to those used at development time, and specify so called abstract reconfig- 1029uration plan like: change the flow between blocks A and B by a flow between A 1030and C. An abstract reconfiguration plan use high level elements and operations 1031which may increase the CPU consumption of reconfigurations compared to low 1032level patches. Typical operations such as pattern matching of components make the 1033design of reconfiguration easier, but they are compute intensive. Instead of embed- 1034ding the implementation of those operations into the satellite middleware, patterns 1035may be matched offline, at the ground station, thanks to the knowledge of the flying 1036software. We therefore define a hierarchy of reconfiguration languages, ranging 1037from high-level constructs presented to the reconfiguration designer to low-level 1038instructions implemented in the satellite runtime. Reconfigurations are compiled 1039in a so called concrete reconfiguration plan before being sent to the satellite. For 1040instance, the abstract plan upgrade A may be compiled to stop A and B; unbind A 1041and B; patch the implementation of A; rebind A and B; restart A and B. This com- 1042pilation process uses proposed techniques to reduce the size of the patch sent to the 1043satellite and the time to apply it [35]. Another interest of this compilation scheme 1044is to enable the use of the same abstract reconfiguration plan to a whole family of 1045satellites. While traditional patch based approaches make it hard to apply a single 1046reconfiguration to a family, each concrete plan may be adapted to the precise state 1047of each of the family member. 1048


Uncor

recte

d Proof

SPaCIFY Project

Applying the previously model driven approach to reconfigurations of satellite 1049software raise a number of other issues that are described in [10]. Work remains to 1050be conducted to get the complete reconfiguration tool chain available. The biggest 1051challenge being the specification of reconfiguration plan. Indeed, considering recon- 1052figuration at the level of the structural model implies to include the reconfigurability 1053concern in the metamodel of Synoptic . If reconfigurability is designed as an abstract 1054framework (independent of the modeling language), higher modularity is achieved 1055when deciding the elements that are reconfigurable. First experiments made on Frac- 1056tal component model [11] allow us to claim that focusing on the points of interest 1057in application models, metadata for reconfiguration are more efficient. Indeed, sep- 1058arating reconfigurability from Synoptic allows to download metadata on demand or 1059to drop them at runtime, depending on requested reconfigurations. 1060

Lastly, applying reconfiguration usually require that the software reach a quies- 1061cent state [28]. Basically, the idea consists in ensuring that the pieces of code to 1062update are not active nor will get activated during their update. For reactive and pe- 1063riodic components as found in the OBSW, such states where reconfiguration can be 1064applied may not be reached. We have proposed another direction [12]. We consider 1065that active code can be updated consistently. Actually, doing so runs into low-level 1066technical issues such as adjusting instruction pointers, and reshaping and relocating 1067stack frames. Building on previous work on control operators and continuation, we 1068have proposed to deal with the low level difficulties using the notion of continuation 1069and operators to manipulates continuations. This approach do not make updating 1070easier but gives the opportunity to relax the constraints on update timing and allow 1071updates without being anticipated. 1072

3.5 Conclusion 1073

Outlook 1074

The SPaCIFY ANR exploratory project proposes a development process and asso- 1075ciated tools for hard real time embedded space applications. The main originality 1076of the project is to combine model driven engineering, formal methods and syn- 1077chronous paradigms in a single homogeneous design process. 1078

The domain specific language Synoptic has been defined in collaboration with 1079industrial end-users of the project combining functional models derived from 1080Simulink and architectural models derived from AADL . Synoptic provides several 1081views of the system under design: software architecture, hardware architecture, dy- 1082namic architecture and mappings between them. Synoptic is especially well adapted 1083for control and command algorithm design. 1084

The GALS paradigm adopted by the project is also a key point in the promoted 1085approach. Synoptic language allows to model synchronous islands and to specify 1086how these islands exchange asynchronous information by using the services of a 1087dedicated middleware. 1088


Uncor

recte

d Proof


In particular, the SPaCIFY project proposed a contract approach to the specifica- 1089tion of the relations between applications and the middleware. 1090

This middleware does not only implement common services such as communi- 1091cation or naming, but also offers domain-specific services for satellite flight control 1092software. Reconfiguration is one of these domain-specific services. The SPaCIFY 1093project studied this service with a particular focus on the use of application model 1094to specify reconfiguration. 1095

The Synoptic Environment 1096

The SPaCIFY design process has been equipped with an Eclipse-based modeling 1097workbench. To ensure the long-term availability of the tools, the Synoptic en- 1098vironment rely on open-source technologies: it guarantees the durability and the 1099adaptability of tools for space projects which can last more than 15 years. We hope 1100this openness will also facilitate adaptations to other industries requirements. 1101

The development of the Eclipse-based modeling workbench started with the def- 1102inition of the Ecore meta-model [2] of the Synoptic language. The definition of this 1103meta-model has relied on the experience gained during the GeneAuto project. This 1104definition is the result of a collaborative and iterative process. In a first step, a con- 1105crete syntax relying on the meta-model has been defined using academic tools such 1106as TCS (Textual Concrete Syntax) [27]. This textual syntax was used to validate 1107the usability of the language through a pilot case study. These models have helped 1108to improve the Synoptic language and to adapt it to industrial know-how. Once the 1109language was stabilized, a graphical user editor was designed. A set of structural 1110and typing constraints have been formalized, encoded in OCL (Object Constraint 1111Language), and integrated into the environment. 1112

In parallel of these activities, the semantics of the language was defined. The 1113formal semantics of the Synoptic language relies on the polychronous paradigm. 1114This semantics was used for the definition of the transformation of Synoptic models 1115towards SME models following a MDE approach. This transformation allows to 1116use the Polychrony platform for verification, semantics model transformation hints 1117for the end user, such as splitting of software as several synchronous islands and 1118simulation code generation purposes. 1119

The Synoptic environment is being used to develop case studies of industrial size. 1120

Future Investigations 1121

The Synoptic environment is based on model transformation. Thus, verifying this 1122transformations is a key point. It has been addressed in the Geneauto project to cer- 1123tify sequential code generation from a Stateflow/Simulink based language. This 1124work must be extended to take into account features of the execution platform 1125such as timers, preemption-based schedulers, multi-threading, multi-processors, . . . . 1126Work is in progress on a subset of the Synoptic language. 1127


Uncor

recte

d Proof

SPaCIFY Project

The Synoptic environment provides a toolset supporting a development process. 1128Experience acquired during the SPaCIFY project with industrial partners has en- 1129lighten two different processes and thus the need to parameterize the platform by 1130the process. A SPEM-based specification of the development process could be used 1131as input of a generic platform so that it could be configured to match end user current 1132and future development method. 1133

The Synoptic environment offers a limited support to refinement-based develop- 1134ment process. This support could be extended and coupled with versioning to allow 1135refinement checking between any couples of models or submodels. It means a sup- 1136port for defining and partially automatically generating gluing invariants between 1137models. Then proof obligations could be generated. 1138

References 1139

1. Altarica Project. http://altarica.labri.u-bordeaux.fr/wiki/. 11402. Eclipse Modeling Framework project (EMF). http://www.eclipse.org/modeling/emf/. 11413. RT-Builder. Solutions for Real-Time design, modeling and analysis of complex, multi- 1142

processors and multi-bus systems and software. http://www.geensys.com/?Outils/RTBuilder. 11434. Simulink. Simulation and model-based design. http://www.mathworks.com/. 11445. ASSERT Project. Automated proof-based system and software engineering for real-time sys- 1145

tems. http://www.assert-project.net/, 2007. 11466. As-2 Embedded Computing Systems Committee SAE. Architecture Analysis & Design Lan- 1147

guage (AADL). SAE Standards no AS5506, November 2004. 11487. Albert Benveniste, Patricia Bournai, Thierry Gautier, Michel Le Borgne, Paul Le Guernic, 1149

and Herv Marchand. The Signal declarative synchronous language: controller synthesis and 1150systems/architecture design. In 40th IEEE Conference on Decision and Control, December 11512001. 1152

8. U. Brinkschulte, A. Bechina, F. Picioroaga, and E. Schneider. Open System Architecture for 1153embedded control applications. In International Conference on Industrial Technology, vol- 1154ume 2, pages 1247–1251, Slovenia, December 2003. 1155

9. Christian Brunette, Jean-Pierre Talpin, Abdoulaye Gamatie, and Thierry Gautier. A meta- 1156model for the design of polychronous systems. Journal of Logic and Algebraic Programming, 115778(4):233–259, 2009. 1158

10. Jeremy Buisson, Cecilia Carro, and Fabien Dagnat. Issues in applying a model driven approach 1159to reconfigurations of satellite software. In HotSWUp ’08: Proceedings of the 1st International 1160Workshop on Hot Topics in Software Upgrades, pages 1–5, New York, NY, USA, 2008. ACM. 1161

11. Jeremy Buisson and Fabien Dagnat. Experiments with fractal on modular reflection. In SERA 1162’08: Proceedings of the 2008 Sixth International Conference on Software Engineering Re- 1163search, Management and Applications, pages 179–186, Washington, DC, USA, 2008. IEEE 1164Computer Society. 1165

12. Jeremy Buisson and Fabien Dagnat. Introspecting continuations in order to update active code. 1166In HotSWUp ’08: Proceedings of the 1st International Workshop on Hot Topics in Software 1167Upgrades, pages 1–5, New York, NY, USA, 2008. ACM. 1168

13. Alan Burns. The Ravenscar profile. ACM Ada Letters, 4:49–52, 1999. 116914. Alan Burns, Brian Dobbing, and Tullio Vardanega. Guide for the use of the Ada Ravenscar 1170

Profile in high integrity systems. Ada Letters, XXIV(2):1–74, 2004. 117115. F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-oriented software 1172

architecture: a system of patterns. Wiley, New York, 1996. 1173

http://altarica.labri.u-bordeaux.fr/wiki/

http://www.eclipse.org/modeling/emf/

http://www.geensys.com/?Outils/RTBuilder

http://www.mathworks.com/

http://www.assert-project.net/


Uncor

recte

d Proof


16. F.-X. Dormoy. Scade 6: a model based solution for safety critical software development. In 1174Proceedings of the 4th European Congress on Embedded Real Time Software (ERTS ’08), 1175pages 1–9, Toulouse, France, January–February 2008. 1176

17. ESA. European space agency. ground systems and operations – telemetry and telecommand 1177packet utilization (ECSS-E-70), January 2003. 1178

18. Sanford Friedenthal, Alan Moore, and Rick Steiner. A practical guide to SysML: the systems 1179modeling language. Morgan Kaufmann, San Francisco, CA, 2008. 1180

19. James Gosling, Bill Joy, Guy Steele, and Gilad Bracha. Java(TM) language specification, 3rd 1181edition. Addison-Wesley, New York, 2005. 1182

20. Object Management Group. CORBA Component Model 4.0 Specification. Specification 1183Version 4.0, Object Management Group, April 2006. 1184

21. Paul Le Guernic, Paul Le Guernic, Jean-Pierre Talpin, Jean pierre Talpin, Jean-Christophe Le 1185Lann, Jean christophe Le Lann, and Projet Espresso. Polychrony for system design. Journal 1186for Circuits, Systems and Computers, 12:261–304, 2002.AQ5 1187

22. Paul Le Guernic, Paul Le Guernic, Jean-Pierre Talpin, Jean pierre Talpin, Jean-Christophe Le 1188Lann, Jean christophe Le Lann, and Projet Espresso. Polychrony for System Design. Journal 1189for Circuits, Systems and Computers, Special Issue on Application Specific Hardware Design, 119012:261–304, August 2003. 1191

23. N. Halbwachs, P. Caspi, P. Raymond, and D. Pilaud. The synchronous dataflow programming 1192language LUSTRE. In Proceedings of the IEEE, pages 1305–1320, 1991. 1193

24. David Harel. Statecharts: a visual formalism for complex systems. Science of Computer Pro- 1194gramming, 8(3):231–274, 1987. 1195

25. Jerome Hugues, Bechir Zalila, and Laurent Pautet. Combining model processing and middle- 1196ware configuration for building distributed high-integrity systems. In ISORC ’07: 10th IEEE 1197International Symposium on Object and Component-Oriented Real-Time Distributed Comput- 1198ing, pages 307–312, Washington, DC, USA, 2007. IEEE Computer Society. 1199

26. Damir Isovic and Gerhard Fohler. Efficient scheduling of sporadic, aperiodic, and periodic 1200tasks with complex constraints. In 21st IEEE Real-Time Systems Symposium (RTSS’2000), 1201pages 207–216, Orlando, USA, November 2000. 1202

27. Frederic Jouault, Jean Bezivin, and Ivan Kurtev. Tcs:: a DSL for the specification of textual 1203concrete syntaxes in model engineering. In GPCE ’06: Proceedings of the 5th international 1204conference on Generative programming and component engineering, pages 249–254, New 1205York, NY, USA, 2006. ACM. 1206

28. J. Kramer and J. Magee. The evolving philosophers problem: dynamic change management. 1207IEEE Transactions on Software Engineering, 16(11):1293–1306, November 1990. 1208

29. Object Management Group Management Group. A UML profile for MARTE, beta 2. Technical 1209report, June 2008. 1210

30. Peter J. Robinson. Hierarchical object-oriented design. Prentice-Hall, Upper Saddle River, NJ, 12111992. 1212

31. Jean-Franois Rolland, Jean-Paul Bodeveix, Mamoun Filali, David Chemouil, and Thomas 1213Dave. AADL modes for space software. In Data Systems In Aerospace (DASIA), Palma 1214de Majorca, Spain, 27 May 08 – 30 May 08, page (electronic medium), http://www.esa.int/ 1215publications, May 2008. European Space Agency (ESA Publications). 1216

32. E. Schneider. A middleware approach for dynamic real-time software reconfiguration on dis- 1217tributed embedded systems. PhD thesis, INSA Strasbourg, 2004. 1218

33. Brinkley Sprunt, John P. Lehoczky, and Lui Sha. Exploiting unused periodic time for aperiodic 1219service using the extended priority exchange algorithm. In IEEE Real-Time Systems Sympo- 1220sium, pages 251–258, Huntsville, AL, USA, December 1988. 1221

34. Andres Toom, Tonu Naks, Marc Pantel, Marcel Gandriau, and Indra Wati. GeneAuto: an au- 1222tomatic code generator for a safe subset of SimuLink/StateFlow. In European Congress on 1223Embedded Real-Time Software (ERTS), Toulouse, France, 29 January 08 – 01 February 08, 1224page (electronic medium), http://www.sia.fr, 2008. Socit des Ingnieurs de l’Automobile. 1225

35. Carl von Platen and Johan Eker. Feedback linking: optimizing object code layout for updates. 1226SIGPLAN Notices, 41(7):2–11, 2006. 1227

http://www.esa.int/publications

http://www.esa.int/publications

http://www.sia.fr

chapter 3 synoptic: a domain-speciﬁc modeling language for...

Documents