B-space: dynamic management and assurance of open systems of systems

2.1 Safety Assurance in a Nutshell

Before we analyze safety assurance challenges for open systems of systems, a basic, common understanding of safety assurance in general is provided in the following.

The precise definition of safety assurance, and particularly of the terms used, depends on the respective application domain. The principal idea, however, is similar across all safety-related application domains. For the sake of simplicity, we therefore use the terms as defined in ISO 26262 [7], which is the relevant safety standard for automotive systems. It is at the same time one of the most recent safety standards.

The overall goal of safety engineering is to ensure ‘freedom from unacceptable risk’ [7]. The term risk is defined as the ‘combination of the probability of occurrence of harm and the severity of that harm’ [7]. Usually, however, it is not possible to directly assess the harm that is potentially caused by a system. Instead, safety managers identify the hazards of a system, i.e., ‘potential sources of harm’ [7]. In many domains, this vague definition is further refined. In the automotive domain, for example, ‘hazards shall be defined in the terms of conditions and events that can be observed at the vehicle level’ [7]. Usually, harm is only caused when a hazard, a specific environmental situation, and a specific operation mode of the system coincide. This coincidence is called ‘hazardous event’ [7].

The identification of these hazardous events and the assessment of the associated risks is the first step in any safety assurance lifecycle, namely the’ hazard analysis and risk assessment (HRA)’ as shown in Fig. 1. This step is performed during the very early phases of the development process, at the latest when the system requirements are available.

As a result of this step, safety goals are defined as top-level safety requirements, which have to be incrementally refined during the safety assurance lifecycle. Usually, any safety requirement consists of a functional part and an associated integrity level. The functional part defines what the system must (not) do, whereas the integrity level defines the rigor demanded for the implementation and verification of this requirement. The integrity level depends on the risk associated with the hazardous event that is addressed by the safety goal. For example, ISO 26262 defines so-called automotive safety integrity levels (ASIL).

In order to break down the safety requirements, the subsequent steps in the safety assurance process should be performed in parallel to the development activities. To this end, the available development artifacts are used as input to safety analyses in order to identify potential causes of the identified system failures. A wide range of established analysis techniques is available. Failure Modes and Effects Analysis (FMEA) and Fault Tree Analysis (FTA) are certainly the most widely used safety analysis techniques in practice.

Based on these results, a safety manager derives a safety concept. Following the idea of ISO 26262, a safety concept can be defined as a ‘specification of the safety requirements, their allocation to architectural elements and their interaction necessary to achieve the safety goals, and information associated with these requirements’ [7]. In the same way as the developers incrementally refine the system over the different development phases, the safety manager analyzes the refined development artifacts step by step and refines the safety concept accordingly.

Finally the safety manager has to define a safety case, which forms the basis for certification. A safety case can be defined as an ‘argument why an item is safe supported by evidence compiled from work products of all safety activities during the whole lifecycle’ [7]. Actually, a safety case can be derived from a safety concept by extending the latter with evidences proving that the requirements have been fulfilled. Evidence might be anything supporting an argument in the safety case. Evidences of particular importance are the results of validation and verification activities as well as safety analysis results. Since a safety case compiles all evidences that are relevant for proving the system’s safety, it is an efficient basis for safety certification.

2.2 Safety challenges in open Systems of Systems

Such an established, conventional safety assurance process presumes that the system including all its constituents and all possible configurations and modes of operation are completely known prior to a final certification. Any kind of modification is considered as modification requiring re-certification of the system. Obviously this leads to various challenges for the safety assurance of open systems of systems.

The structure and, in consequence, the resulting collective behavior of open systems of systems is not known at design time. Systems dynamically enter and leave the collective and the constituent systems continuously adapt themselves in order to provide optimized performance in that dynamically changing context. Even in the case of reconfiguration as one of the weakest variants of self-adaptation, and even if all possible configurations of all constituent systems were known at design time, the resulting permutation of configurations would lead to a state space explosion impeding any design time analysis. More flexible self-adaptation approaches would – from a safety point of view – be comparable to a software modification requiring complete re-certification of the system. And, in fact, as they are heterarchical systems, there is no central integrator in open systems of systems who could be responsible for the safety assurance of the resulting system collective. Instead, the systems integrate themselves dynamically at runtime and a final safety assessment of the integrated system of systems by a human safety assessor is impossible.

While the safety assurance community still strongly focuses on very static systems, the dependability engineering community already addresses these challenges by evolving from dependability to resilience [8, 9]. Resilience in this context is defined as “the persistence of dependability when facing changes”. Changes are characterized in three dimensions as shown in Fig. 2: The nature of a change may be functional, environmental, or technological. The prospect of a change may be foreseen, foreseeable, or unforeseen. The timing of a change may be short term, medium term, or long term.

Obviously, the main challenges of open systems of systems result from changes, namely from changing structures and behavior (functional), from changing context (environmental), and partly from changing technologies, such as changing communication technologies. Applying the idea of resilience to assuring the safety of open systems of systems therefore leads to the challenge of guaranteeing the “persistence of safety when facing changes”.

2.3 Openness

So far, we have talked about open systems in general. In an open system of systems, individual systems, so-called constituent systems, dynamically connect to each other in order to collectively provide value-adding superordinate functionality. Instead of hierarchical systems, this leads to heterarchical systems of systems. This means that there is no hierarchy, but all systems have equivalent rights and have their own mission and objectives. They are usually developed independently by independent companies, which have their own business goals, strategies, and missions. In contrast to closed systems, this also means that there is no central integrator, no OEM, who is responsible for the final integration and who is liable for the quality of the overall system of systems. Nonetheless, the constituent systems need to collaborate as a collective – just as individual people work together in teams – aiming for joint goals and by following certain rules. In order to realize an open system of systems, the structure and behavior of an open system of systems dynamically emerge at runtime, leading to very flexible and adaptive solutions. In consequence, the single constituent systems need to adapt themselves to such a dynamic context.

To define a safety assurance approach for open systems of systems, we need to take a closer look at the property of openness. Therefore, we suggest a classification that primarily reflects those classification criteria that are of importance for safety assurance. The different possible degrees of openness are illustrated in Fig. 3.

Closed system means there is a final integrator who guarantees the system’s safety. This also means that the system will not change its structure beyond the configuration space considered during the safety assessment – i.e., its safety can be analyzed completely during development time since everything relevant is known. Taking the example from the agricultural domain mentioned in the introduction, the tractor as well as the baler would be closed systems.

If we regard open systems of systems, it is important to distinguish between closed ecosystems on the one hand and open ecosystems on the other hand. Even though the systems integrate themselves dynamically and flexibly at runtime, a closed ecosystem means that all the systems must follow the same rules. And all possible ways of collaboration are known – at least at an abstract level. For example, agriculture defines such a closed ecosystem. The tractor and the baler follow a common communication standard, and it is possible to define common safety rules and guidelines within the industry. Moreover, the ways in which a tractor and an implement may interact are known and can be analyzed for an ecosystem – even though the concrete combination of tractor and implement is unknown at design time. From a safety perspective, we can thus state that we are dealing with foreseeable changes, which can be addressed through adequate runtime support, as we will further discuss in this article. In an open ecosystem, however, such rules are not available, as, for example, systems of various different industries need to collaborate in an ad-hoc manner without prior design time consideration of the unfolding collaborations. This means that it is hardly possible to define common safety rules (in the sense of a generic safety concept suitable for any conceivable collaboration during runtime) because we cannot predict which (types of) systems will eventually interact in which way. Referring to the definition of resilience, this means, in particular, that assuring safety in open ecosystems means handling unforeseeable changes. Although open ecosystems pose very interesting research challenges, we will focus on closed ecosystems in this article as an intermediate step between today’s closed systems and those open ecosystems foreseen for the distant future.

Considering open systems in closed ecosystems, we further distinguish between on-duty integration (concurrent integration and operation) on the one hand and off-duty integration (preemptive integration) on the other hand. Off-duty or preemptive integration means that the operation of the system of systems is suspended when its structure changes. For example, the tractor and the baler can be set to a special integration mode and it is possible to check the safety of the resulting system of systems before it starts operation. This means, in particular, that there is sufficient time to perform a safety analysis at the integration level. In addition, even though a farmer is not a safety expert, he might be involved in the checking process, e.g., by performing and confirming manual checks. These advantages are not true in the case of on-duty or concurrent integration. In this case, the structure of the system of systems might change dynamically while it is operating. If we take a crossroads assistant as a Car2X (cars communicating amongst each other or with other entities to realize cooperative services) scenario as an example, the cars approaching a crossroads must dynamically form a system of systems to manage the right of way collectively. Obviously, it is not an option to stop the cars to check the safety of the resulting system of systems before it continues operation. Consequently, on-duty integration poses much higher demands on the required runtime safety assurance approaches since there are hard real-time constraints and user intervention is not possible.

2.4 Safety models at <<run.Time>>

In order to handle changes in general, self-adaptation has evolved as a promising approach for enabling systems to flexibly and nonetheless systematically adapt themselves to changes. Models@Run.Time [5] provides a particularly interesting basis for self-adaptation as it makes adaptations tangible and explicit, which is of utmost importance for safety assurance. In previous work, we therefore introduced the idea of safety models at runtime (SM@RT), which can be used to assure the safety of adaptive systems [2, 4, 10].

In general, “a model@run.time is a causally connected self-reflection of the associated system that emphasizes the structure, behavior, or goals of the system from a problem space perspective” [5]. Applied to safety this means that we shift modified safety models (such as certification models, safety case models, or safety concept models) to runtime. Using self-reflection and monitoring mechanisms, the models are continuously updated to reflect the associated systems’ safety state. Based on these safety models at runtime, the system is enabled to systematically reason about and take actions for preserving the system’s safety at runtime. To this end, it is possible to apply model-based runtime analyses, which have their origin in established and accepted model-based safety analyses used in conventional safety assurance approaches. This means that safety models at runtime can be seen as an evolution of model-based safety assurance, which increases the likelihood of acceptance by certification bodies. Our approach is based on safety certificates at runtime, which we will describe in more detail in the section Certificates at Runtime, and has proven its applicability and acceptance in different industrial applications involving independent certification bodies.

Thus, we essentially need to shift “safety intelligence” from development time to the systems’ runtime models in order to enable dynamic safety assurance and management. The question, however, is now how much safety intelligence can and should be shifted to runtime. Considering the need to always provide a sound safety argument, which typically is a creative task requiring a lot of experience, it makes sense to try to keep as much of it as possible at design time. This means, in turn, that we only shift aspects to runtime that cannot be resolved at design time already due to non-resolvable uncertainties. Still, higher levels of safety intelligence at runtime can provide more flexibility and a more optimized “trade-off” between safety and performance. For further reference, we briefly discuss such levels in [11, 12].

As a related issue, we would like to emphasize that the need to shift safety models and management to runtime is not only a burden. It also opens up a huge potential in terms of optimizing performance while ensuring safety at any point in time. The reason for this is that in traditional approaches, any volatile property of the environment had to be considered in the sense of a worst-case assumption, thus leading to designs and parameterizations with sub-optimal performances. Now, when safety-related properties and dependencies are made explicit and analyzable at runtime, the performance levels of a system could be adjusted dynamically based on, for instance, the current safety and general quality properties of a sensor. This, of course, goes into both directions; i.e., if the quality of information deteriorates or if there is a sensor failure (for example), graceful degradation (of the application performance) can be conducted – which is done quite frequently today. Another promising opportunity is to build some flexibility into the top-level safety goals (or in the way safety goals are selected, interpreted, and refined based on changing situations); in other words, to shift aspects of the hazard and risk analysis to runtime. Here it would be conceivable to factor in information regarding the usage context. An example would be an agricultural machine operating on a perfectly flat and dry field versus the same machine operating on difficult topography and wet soil. The first case could have less strict safety requirements in some regards, thus enabling a higher level of performance.

Moreover, if the safety guarantees are not sufficient, graceful degradation could be required. This might also happen during operation if, for instance, a sensor fails and the system needs to be dynamically reconfigured in order to replicate the sensor value based on fusion of alternative sensors. If this leads to a deterioration of qualities (and safety guarantees in particular), the overall application might require new parameterization, such as lower top-speed of an automated vehicle. Consequently, in addition to the safety models at runtime, reconfiguration/adaptation models would be required as well. Thinking a bit further into this direction, there would not only be such models operating tactically on short timescales, but ideally also models operating more strategically and on larger timescales.

In essence, we argue that future systems would greatly benefit from comprehensive multi-concern models at runtime operating on different levels, which would enable a dynamically managed informed trade-off between different concerns as well as ecosystem-wide orchestration to facilitate higher-level strategic goals. With that, new application features can be enabled, which are impossible to realize based on the scope of the constituent systems alone.

As a first step towards a corresponding concept, it is important to understand the different types and foci that runtime models might assume. In the following, we will introduce the B-Space concept, which provides an overall vision as well as structure and classifications regarding the interplay of multi-concern models at runtime.

4.1 Certificates at runtime – Conditional safety certificates

In this chapter, we re-iterate the concept of ConSerts as introduced in [2, 3] and outlined in [4] and illustrate how ConSerts are an aspect of and an initial step towards the concept of B-Spaces. In particular, it is shown how B-Space models could look like and what the implications would be with respect to established engineering practice.

ConSerts operate on the level of safety requirements. They are issued at development time and certify specific safety guarantees (i.e., guaranteed safety requirements) that depend on the fulfillment of specific demands (i.e., safety requirements demanded from the environment) regarding the environment. In the same way as “static” certificates, ConSerts shall be issued by safety experts, independent organizations, or authorized bodies after a stringent manual check of the safety argument. To this end, it is mandatory to prove all claims regarding the fulfillment of provided safety guarantees by means of suitable evidence and to provide adequate documentation of the overall argument – including the external demands and their implications.

There are, however, some significant differences between ConSerts and static certificates that are owed to the nature of open systems: A ConSert is not static but variable and conditional; i.e., it comprises a number of variants that are conditional with respect to the (dynamic) fulfillment of demands. Moreover, a ConSert must be available in an executable (and composable) form at runtime (i.e., as a safety model at runtime) and systems must be equipped with corresponding mechanisms to operate on the ConSerts. Conditions within a ConSert manifest in relations between potentially guaranteed safety requirements, which can simply be denoted as guarantees, and the corresponding demanded safety requirements, i.e., demands. Demands always represent safety requirements relating to the environment of a component, which cannot be verified at development time because the required information is not available yet. These demands might directly relate to required functionalities from other components. On the other hand, evidence can be required beyond that since safety is not a purely modular property and it cannot be assumed that a composition of safe components is automatically safe. To this end, ConSerts support the concept of so-called Runtime Evidences (RtE) as an additional operand of the conditions. RtEs are a very flexible concept. In principle, any runtime analysis providing a Boolean result can be used. RtEs might relate to properties of the composition or to any context information, e.g., a physical phenomenon such as the temperature of the environment that is safety-relevant and could be measured with a sensor. Other RtEs require dynamic negotiation between components, such as for determining independence between different services used. To this end, a dedicated protocol could be used that builds traces through the composition hierarchy starting from the services in question to identify common elements in the traces.

Accordingly, a ConSert can be specified as a set of Boolean functions, which, in turn, can generally be represented by a corresponding set of (potentially overlapping) rooted directed acyclic graphs in a graphical specification. The root of each of these directed acyclic graphs is constituted by a potential safety guarantee, which becomes true if, at runtime, related (according to the Boolean logic) demands and runtime evidences are satisfied. Each graph consists of:

• A set of Boolean input variables; i.e., demands and runtime evidences

• A set of Boolean gates; i.e., {and, or}

• A set of directed edges connecting the elements

• A Boolean output variable; i.e., the guarantee

The guarantees and demands can be specified based on the grammar introduced in [3]. An example follows later in this article.

Note that ConSerts are designed to harmonize with the pre-engineered dynamic reconfiguration. Each constituent system (/component) can have a series of configurations, which can be switched at runtime. Each of these configurations is characterized by a specific profile of required and provided services and equipped with its own specific ConSert, which provides the mapping function between guarantees, demands and runtime evidences as described above (cf. Figure 5). Within the B-Space, the reconfiguration models are an important additional ingredient for enabling not only dynamic assessment of safety guarantees, but also their management and enforcement.

To be utilized as a runtime model of the B-Space, ConSerts (as well as other relevant models) need to be transferred into a suitable representation. Suitability clearly depends on the characteristics of systems and domains and on the corresponding constraints. When we are talking about tiny microcontrollers where resources are very scarce, it may make sense to bring ConSerts into a BDD representation (i.e. a set of BDDs, one for each potential guarantee) [2, 3], which can be optimized at development time to enable very easy evaluation and a minimal memory footprint at runtime. If we are talking about more powerful IoT devices, an XML-based representation might be more appropriate, and if an Internet connection is always available, even a cloud-based ConSert evaluation is conceivable. Looking at the B-Space as a whole, different runtime models for different concerns might reside in different places. ConSerts and reconfiguration models might be distributed modularly over all constituent systems, while other models, such as those working on a larger time scale and with a more strategic scope, may reside and be managed in the cloud.

At runtime, dynamic hierarchies are formed when a top-level application is instantiated in an open adaptive system of systems. Thus, the top-level application requires basic services from other systems, which might in turn require basic services from yet another system, and so on. In this process of forming a dynamic hierarchy, involved constituent systems might be reconfigured/adapted to be fit for their tasks. This also implies that constituent systems deliver services for consumers of different composition hierarchies. Therefore, a heterarchical system-of-systems structure is formed overall.

Throughout these hierarchies, ConSerts are composed and evaluated, yielding the current safety guarantees for the respective hierarchy at their root node. The evaluation is performed from leaves to root, starting from leaf ConSerts that have only runtime evidences and no demands. Generally, based on the fulfillment of demands and runtime evidences, it is determined for each ConSert through Boolean logic which of its potential guarantees are currently valid. If several guarantees of a ConSert are valid, one (i.e. the “best” one) shall be selected. This can be done based on a simple absolute order from best to worst over the guarantees of a ConSert or based on more sophisticated utility functions, which might include context information in the equation to make a more informed decision on what is actually to be considered “best” under given circumstances.

Based on the continuously monitored safety guarantees, managing actions might be performed by the system(s) in the sense of the MAPE-M@RT (monitoring, analysis, planning and execution based on models at runtime) [13] control loop. Thus, the context is monitored and the current safety guarantees are determined; it is analyzed whether the system has the appropriate configuration and parameterization; potential adaptations are planned and executed – all based on the M@RT of the B-Space, in particular the ConSerts and correlated adaptation/reconfiguration models.

4.2 Example

We further illustrate ConSerts with an example from the agricultural domain, which has previously been presented in [4]. The agricultural domain today pioneers innovative applications involving systems of systems and dynamic integration. One of these applications is the so-calledTractor Implement Management (TIM). The TIM functionality enables agricultural implements to control typical tractor functions such as velocity, steering angle, power take off, or auxiliary valves. It is possible to fully automate implement-specific work procedures and to optimize them with respect to parameters such as performance, efficiency, or wear and tear. TIM utilizes a standardized bus system for communication between the participating devices and machines. During TIM operation, control is typically assumed by the implement. It uses the TIM functions of the tractor (e.g., controlling velocity, steering angle, power take-off, hydraulic valves) and auxiliary devices, such as sensors for the respective automation purpose, displays data to the operator, and executes operator inputs. Between different tractors, implements, and auxiliary devices such as virtual terminals (providing the operator UI) or GPS systems of different manufacturers, a huge space of configurations arises, which makes it unfeasible to analyze each potential configuration a priori at development time. For this reason, those TIM applications already available on the market today only work for predetermined concrete pairs of tractors and implements whose integration has been thoroughly analyzed at development time by the involved manufacturers.

The benefit of ConSerts (or SM@RT in general) in this setting is pretty clear. Assume there is a farmer who owns a TIM-capable tractor and a TIM-capable round baler. The TIM baling application is running on the implement, and the user interface is displayed on a virtual terminal in the cabin. In addition to a standard configuration, the baling application also supports an extended configuration, which additionally incorporates a swath scanner device. This device is mounted on the front of the tractor and measures the volumetric flow and the location of the swath to further optimize the baling operation in terms of tractor speed and steering angle. The baling application can then be enabled when tractor, implement, virtual terminal, and swath scanner are connected and the automated ConSert-based interoperability and safety checks have been successful. Corresponding information is provided to the operator via the terminal. Parameterization and constraints are set appropriately. The actual round baling process can then be activated by the operator, who thus relinquishes control to the round baler. The round baler commands the tractor to drive over the swath with optimal acceleration rates and speed. When the bale reaches a preset size, the tractor decelerates to a standstill and the bale is ejected. The process can then be re-started by the operator.

4.3 Engineering of ConSerts

For the engineering of ConSerts, the role and viewpoint of the implement manufacturer are assumed in this example. The goal of the manufacturer is to develop a round baler with TIM support. From a functional point of view, it is known by the manufacturer (due to existing standards) what the interfaces between the potential participants look like and how they are to be used. However, the implement manufacturer does not know anything about the safety properties of these functions.

From a safety point of view, the engineering of the baling application starts top-down with an application-level hazard and risk analysis. Assume that the agricultural manufacturers agreed by convention that during the operation of a TIM application, the application (and thus the application manufacturer) has the responsibility for the overall automated system. Therefore, the safety engineering goal is to ensure adequate safety not only for the TIM baling application or for the implement, but for the whole collaboration of systems that will be rendering the application service at runtime. Thanks to the ConSert-based modularization, it is thus sufficient to only consider the direct dependencies of the system under development on its environment. Potential “external” safety requirements will be associated either with demands regarding required services or with RtEs. At runtime, it will be determined whether the demands can be satisfied based on guarantees given by external systems (which, in turn, might have demands depending on yet (an)other external system(s)). This negotiation can thus range across several layers and incorporate a series of dependent systems and guarantee-demand relationships.

Relating the ConSerts from the example to the classification of B-Space models, we are talking about quality models (i.e., safety). ConSerts will mostly be utilized with an operational scope, but they might as well be input to considerations with a tactical or even strategic scope (e.g., strategic deployment of TIM machines with respect to weather conditions so that their performance over a season can be optimized). As regards the B-Space level where ConSerts reside, this is at least twofold. There are ConSerts at the system level, but due to their compositional and hierarchical nature, there is always at least one ConSert in a composition hierarchy that is at the mission level – the ConSert of the root node of the hierarchy. For this ConSert, the overall collaboration of the cooperative application (i.e., mission) has been considered in the corresponding safety engineering as exemplified above for the TIM baling application. Beyond that, it would also be conceivable to utilize ConSerts at the levels above, system of systems and ecosystems. However, to date we have not engineered any in-depth case study in that respect.

Going back to the engineering of the baler, relevant hazards of the TIM baling application might be self-acceleration or self-steering during operation or self-acceleration or power take-off during standstill. These hazards would be assessed with respect to their associated risks based on the risk assessment tables provided by ISO 25119 (i.e., the safety standard of the agricultural domain). In a subsequent step, corresponding top-level safety requirements would be derived. In addition, reasonable guarantee levels need to be identified. In the given example, it is conceivable that different safety guarantee levels are required for different locations (e.g., in the midst of nothing vs. a field close to a children’s playground) or that guarantee levels are defined in interplay with application-specific parameters (e.g., acceleration or velocity levels, different degrees of automation, etc.) or with relevant conditions of the operating environment (weather, topography).

The next step is to develop a safety concept that ensures the satisfaction of the safety requirements and of the associated ConSert guarantees. This is done in a standard way: Safety analyses are applied to identify cause-effect relationships and to specify the failure logic; corresponding safety measures are identified; and, eventually, a conclusive safety argument is built up that factors in suitable evidence. The main difference to the engineering of closed systems is that besides possible internal causes, there might be external causes that may either be associated with safety properties of the required services or with RtEs. Moreover, there is also some degree of variability to be considered due to different ConSert guarantees and corresponding differences in the correlated demands.

With regard to the causes related to required services, there are two possibilities. First, it is possible to define internal measures, such as error detection mechanisms, so that failures of the required services can be tolerated. Alternatively or in addition, it is possible to demand that the external service provider has to guarantee certain safety properties for the service. These safety properties need to be formalized and standardized for a domain in order to constitute the basis for the definition of ConSerts guarantees and demands. As for the RtEs, two categories can be distinguished: intra-device and inter-device RtEs. The former can be designed and implemented rather freely because they do not require any information from other external systems. The latter do require such information and thus, they need to be standardized or at least described in guidelines for a given domain. In reference to the example, assume that there is a top-level safety requirement that self-acceleration must not occur during standstill. Based on the hazard and risk analyses, it has been determined that this requirement needs to be assigned the integrity level AgPL d¹. However, this is due to a relatively high degree of exposure assumed for bystanders, as would be the case for operation in the vicinity of a residential area. In other areas, AgPL c would be sufficient². With ConSerts, it is now conceivable to optimize the trade-off between availability and safety by factoring in dynamic context knowledge. Specifically, this means that it would be possible to use, for instance, a GPS position and (in this case) annotated map data to distinguish between different usage contexts of the TIM system that imply different levels of safety requirements. Or, based on the vision of B-Spaces, we might have a wealth of up-to-date context information from and about systems and persons in the vicinity at our disposal. Of course, such a context-sensitivity mechanism needs to be safe in its own right, but for now let us just assume this can be done.

Thus, following these considerations, three different levels of ConSert guarantees are defined in the example: a) a high integrity one, enabling full automation features of the TIM application; b) a medium integrity one, enabling full features only in specific areas (or, alternatively, enabling operation with some constraints); and c) a default guarantee that can always be granted, enabling only a very constrained operation, e.g., without acceleration from standstill or automated steering. The high integrity guarantee would include AgPL d for self-acceleration in standstill as well as a series of other relevant guarantees omitted here for the sake of simplicity. The specification of the guarantee given next is based on a grammar [14] and on service types, safety property types, and rules of refinement specified in a domain-specific standard or guidelines:

TIMBalingSwSc(1): AgPL = b, SelfAcc{,Standstill}.AgPL = d, LateAcc{30s,Standstill}.AgPl = d, (...)

The first element of the specification denominates the associated service (by type) and gives an (absolute) order number for the guarantee (from 1 (best) to n (worst)). More sophisticated orderings could be useful but have not been considered yet for ConSerts. The next element describes an integrity level for the whole service. This is basically a shortcut and implies that all safety properties of the service (as specified by the standard or guideline) are guaranteed with the named integrity level. Then follows a series of concrete safety properties, whose types and parameters (for refinement) are also defined by the standard.

The next step from the ConSert perspective is to determine the demands (i.e., service-related demands as well as RtEs) that relate to the identified guarantees. This relation is modeled by means of a Boolean function, where the demands are input variables and the guarantee is the output variable. There is also a corresponding graphical specification technique based on directed acyclic graphs, where each function is represented by a tuple (D, R, BG, E, g): a set of Boolean input variables D representing service-related demands and RtEs R, a set of Boolean gates BG, a set of directed edges E connecting the elements, and a Boolean output variable g.

Overall, a ConSert is a set of such mapping functions, one for each guarantee level (of each offered service/function of a unit of composition). A unit of composition is typically a self-contained piece of hardware and software, i.e., a system. But it could also be just a piece of software, i.e., an application. If deployed concurrently with other applications on a shared hardware and particularly if dynamic download and update shall be possible, it is also important to include vertical dependencies between applications and (shared) resources in the eq. A corresponding extension of ConSerts has been developed in the EMC² project [15–17].

The definition of the guarantees, the demands, and the mapping functions is generally done conjointly with the development of the safety concept and safety argument. In fact, the resulting ConSert becomes an integral part of the safety argument because it needs to be shown in a convincing manner that the ConSert guarantees are actually valid given the fulfillment of their related demands.

4.4 ConSerts at runtime

ConSerts need to be transferred into a machine-readable form to enable dynamic evaluation, and there need to be corresponding mechanisms built into the systems that operate on this information (i.e., ConSerts as SM@RT) to conduct the evaluation. Of course, the evaluation protocols need to be standardized to ensure that every participating system is interoperable from a ConSert point of view. Assume that the operator has installed the swath scanner on the tractor and that tractor and round baler are coupled. The operator initiates TIM via the virtual terminal and explicitly selects the application variant that provides flexible control of speed and steering based on the input from the swath scanner. The first step is now to start the application, i.e., to dynamically integrate the participating systems. After this has succeeded, the evaluation of the safety guarantees of the application is started. Note that the application forms the root of a dynamically formed composition hierarchy (in contrast to basic services or functions, which are rendered by lower-level components/systems and which are consumed by superordinate components/systems) and the correlated ConSert has the scope of this whole system-of-systems application. The evaluation of ConSerts starts from the leaf systems that have no external service-related dependencies. These systems determine their RtEs and propagate them up in the composition hierarchy. Eventually, all service-related demands of the root (i.e., the TIM baling application) can be checked and, together with the evaluation results of the RtEs, the top-level safety guarantees are determined.