Features of a Time-Adaptive Reconfiguration Model for Embedded Software

for Embedded Software

Based on the previous discussion, this section lists the characteristics of reconfigura- tion models targeting embedded software. These characteristics can be divided into characteristics that deal with the underlying system model, characteristics of the recon- figuration model itself, and characteristics of the execution model.

2.2.1 System Model Characteristics

Reconfiguration models targeting embedded software can be categorised as system- specific, domain-specific, or generic (Zhao & Li, 2007a).

System-specific reconfiguration models target software that is strongly tied to the design of the system it is executed on. This specificity of the underlying software enables the model to make assumptions about the software being changed and to manage change in a way that is optimised for a particular system (Hillman & Warren, 2004).

Domain-specific reconfiguration models are defined on system models that model software in a specific domain. Often the software follows a particular architectural style, such as the pipe-and-filter style (Shaw & Garlan, 1996). The specificity of the underlying architecture allows the reconfiguration model to omit some capabilities. For example, a reconfiguration model defined on a stateless pipe-and-filter architecture does not need state transfer capabilities and hence can omit consistency mechanisms (Zhao & Li, 2007a). These reconfiguration models are tied to software of a specific application domain, and cannot be easily transferred to software of other systems in other application domains.

Generic system models target software that can be applied in multiple application domains and a wide range of systems. Examples of generic component models include OpenCom (Coulson et al., 2008), and Think (Polakovic et al., 2006). A characteristics of these system models is that they are defined abstractly, in terms of components and connections between components. Different implementations then map these abstrac- tions to actual systems. The abstract definition supports building composable software, independent of the target system or application. The advantage of a reconfiguration model targeting this kind of software is that it is independent of the actual embedded system used.

2.2.2 Reconfiguration Model Characteristics

Reconfiguration model features include correctness guarantees, the point in time when reconfigurations may be triggered, and the constraints on the number of reconfiguration actions and reconfigurable software entities.

A reconfiguration must ensure that it transforms the software from a correct soft- ware configuration to another correct software configuration, as otherwise the software is not functionable. A correct software configuration is defined by Goudarzi as a con- figuration that has the three following properties: structural integrity requirements are fulfilled, software entities are in a mutually consistent state, and state invariants are maintained (Goudarzi & Kramer, 1996). Structural integrity requirements define the dependency relationships between software entities and the way they need to be config- ured (Almeida et al., 2001). Structural integrity is achieved by updating the references of all entities that use a reconfigured entity. Mutual consistent state means that the execution state of a reconfigurable software entity should be the same before and af- ter the reconfiguration takes place. Mutual consistent state can be achieved by first bringing the entities into a reconfiguration-safe state, before the actual reconfiguration is executed. However, this is an intrusive process that takes execution duration. An alternative to first bringing the entities into a mutual consistent state is to apply transi-

tional reconfiguration that maintains the old and new system configuration in parallel, see Section 2.1.3. Maintaining state invariants is achieved by transferring state between the old and the new software entity.

Reconfiguration approaches differ in whether a reconfiguration is directly executed when it is triggered, or whether it is executed in a delayed fashion, after some other activity has finished completion. Moreover, approaches differ in whether they support an arbitrary number of entities to be reconfigured, for example by supporting the integration of previously unknown software entities, or whether they put constraints on the number of entities to be reconfigured.

2.2.3 Execution Model Characteristics

A reconfiguration that is correct and fulfils a system’s constraints must reach a consistent state by either completing all its actions eventually or by undoing some of the actions, already executed. Depending on its associated execution model, reconfiguration models either react to incoming events that occur arbitrarily, and process them within their deadline, or do not consider incoming events at all.

2.2.4 Summary

This section summarises the set of characteristics of reconfiguration models targeting embedded software, and their possible values. The values, which are most likely to suit a time-adaptive reconfiguration model are shown in bold. Based on this, a set of characteristics for a time-adaptive reconfiguration model is derived.

• System Model

– Entities: system-specific, domain-specific,general

• Reconfiguration Model

– System correctness: quiescent state,transitional approach

– Possible number of entities to be reconfigured: constrained,unconstrained

• Reconfiguration Execution Model

– Guaranteed reconfiguration completion: Supported due to transactional

execution model, not supported

– React to previously unknown incoming events: Supported due to preemp-

tive execution model, only supported for known events, not supported

These characteristics lead to the following set of required features for a time-adaptive reconfiguration model:

• System Model

F1) The reconfiguration model is defined for a system model suitable for repre- senting embedded software.

• Reconfiguration Model

F2) A reconfiguration can be triggered at any time and there is no a-priori knowl- edge of the possible components that are to be reconfigured in the system. F3) The reconfiguration model does not destroy system correctness.

F4) The reconfiguration model itself does not impose constraints on the reconfig- urable entities.

F5) There are no restrictions on the number of components to be reconfigured.

• Reconfiguration Execution Model

F6) An ongoing reconfiguration is to be completed.

F7) The reconfiguration model allows the interruption of the ongoing reconfigu- ration by incoming events that are previously unknown to the system.

F8) The reconfiguration model meets an incoming event’s processing deadline. These features are used in the next section to review existing reconfiguration models targeting different kinds of embedded software.