- This paper presents and illustrates an approach that allows designers exploring and reasoning, checking and then arguing the consistency of the operat- ing modes of a system. The goal is to help designers to build system's functional architecture by linking operating modes, allowed configurations and operational scenarios i.e. the set of functions displayed by the system in each mode in order to fulfill its mission taking into account its current configuration, requirements and environment. This approach is implemented as a guide called OMAG and is here illustrated on a vehicle design.
System Engineering (SE)
-‐ To become able to imagine how the system can evolve from an operating mode to another one when considering various events (external coming from environment as internal coming from the system itself e.g. dysfunctions) and system configurations. -‐ To model the expected behavior of the system when considered in each retained operating mode. It is here question to model various operational scenarios for each mode, each operational scenarios showing what are the requested functions of the system in this mode and how these functions are then dynamically processed.
-‐ To precise then what are the links between modes, configurations and
scenarios allowing then to improve the coherence of the entire model of the
system.
-‐ To analyse the resulting behavior of the sy
Considering modeling needs, designers often use their experience, know-how,
sometimes approaches based on creativity e.g. brain storming or mental
representation. They can also use, when they are formalized, best practices, design patterns
Considering analysis aspect,
Last, this guide has to be fully interoperable with existing modeling languages and tools currently used in system engineering domain. This article presents the OMAG concepts and principles briefly illustrated on the case of a vehicle named VERECINT. Second, it presents the basics of the verification approach before concluding about perspectives and developments.
VERECINT is a vehicle allowing firemen and experts in the field of chemical, biological, radiological, and nuclear (CBRN) crisis to explore, to evaluate the different elements characterizing a crisis situation (data e.g. temperature or radiation level, information and expertise e.g. that follows the observation and the expertise of a phenomenonon on the site), and to communicate them to crisis managers hav- ing to decide actions to take. VERECINT has then to be able to act accordingly to these actions. At this stage, we assume that VERECINT mission, purpose and ob- jectives as environment (other systems in interaction all along its life cycle and enabling systems), requirements, life cycle and all or part of requirements have been defined. These element cannot be detailed in this article.
1 The set of principles and rules allowing a model (defined here as an instance of a modeling language) execution
OMAG (Operating Modes Analysis Guide) is a graphical guide proposing a set of pre-defined Operating Modes and of pre-defined Transitions between Operating Modes considered as generally relevant and helpful for various kinds of systems. Applied in VERECINT case, OMAG is diagrammed in Appendix. Let’s notice for instance that VERECINT as any a system to be designed must 1) fulfill its mission is some nominal Operating Modes, 2) have to ensure either the continuity of ser- vice of this mission as much as possible in non-nominal Operating Modes, and 3) assume security of goods, people and its immediate environment. Then, before presenting briefly the requested elements of OMAG, let’s reformulate its goals as follows: -‐ To allow a designer to select and choose what are the relevant Operating Modes and Transitions (evolution conditions and events) by taking into account a list of Operating Modes and Transitions having generally to be taken into account. This choice has to be made accordingly to the available knowledge about system definition, the current state of the set of requirements and about system environment.
-‐ To determine gradually what are the possible, unavoidable or interesting configurations of the system and having then to be considered.
-‐ To facilitate the modeling of operational scenarios relevant in each mode i.e. to guide the research of the requested functions of the system and the description of how they have to be dynamically associated to describe the expected behavior of the system.
-‐ To allow designers to trace these choices, to change or modify a choice during design activities and to check, evaluate and compare alternatives solutions of functional architectures induced by these choices.
Considering a system S, OMAG (see Figure 1) requires to define first a set A of data from time, shape or space nature. These ones are chosen and can be evaluated or estimated in order to characterize the temporal aspect (time), the structural as- pect (shape) and the situational aspect (space) of S and of its environment. They do not specify any candidate for architectural solution of S. They aim only to take into account as far as possible, for instance, dimensional constraints, specific at- tributes, expected delays, speed i.e. non functional requirements. A is initialized at the beginning of the design process and enriched bit by bit. Second, OMAG high- lights three main Phases named respectively Deployment, Exploitation and End of life. A Phase is a set of Operating Modes of S that are logically linked or depend- ent. The Exploitation Phase is it self divided into Operating, Maintenance and De- fault sub phases.
An Operating Mode of S is a state reachable by S during its life cycle exhibiting then particular behaviors. By hypothesis, S is in one and only one Operating Mode called active Operating Mode (conversely, disabled) at each moment of its evolution. Each Operating Mode O of S is characterized by (E, C, OSO, T) where: -‐ E is defined by a name and a set SE A. It aims to describe the environment of S, even partial or simplistic i.e. the context in which S has to be able to execute various functions when O is active. For instance VERECINT may evolve the night, under snow or rain, or on roads that may be damaged due to the crisis. -‐ The set C contains one or several Configurations relevant for S in O. A configuration c determines and refines the description of the state of S when it is in O. VERECINT can be for example described by configurations named ‘exercice’, ‘operation on SEVESO site (site containing large quantities of dangerous substances)’ or ‘operation on a city’. A configuration c is defined by a name and a set Sc A defining the requested data from A to describe the configuration. At least one Configuration is required for S, then considered as default configuration c0. Last, S can evolve from a Configuration c to another Configuration c’ crossing a Transition as explained below. -‐ The set OSO contains one or several Operational Scenarios describing expected behavior of S when S is characterized by the current configuration. An Operational Scenario is defined by a functional model compose of a set of functions dynamically linked i.e. a part of S functional architecture describing how S must fulfill its mission. The behavior of VERECINT can be for instance specified by a scenario ‘To observe and to measure specific values from crisis area’.
-‐ The set T contains one to several input and output Transitions. A Transition links a source object here an Operating Mode O (or a configuration C) to a target object i.e. an Operating Mode O’ (or configuration C’). A input Transition describes how O’ (resp. C’) can be reached (O’ or C’ are then activated). Conversely, an output Transition describes how O or C are deactivated. A Transition is then formalized by a 6-uplet (source, destination, c, e, d, [op]) where source and destination describes respectively source object and destination object, c is the tiggering condition (computed taking into account data from A), e is the initiating event (internal to S or coming from the environment) and d is the delay (null by default, but allowing to describe for instance duration of a requested reconfiguration time) under which S can evolve from the source to the target (from the same Phase or not). Last, a Operational Scenario op describing the behavior of S when it is reconfigured can be associated to the Transition.
Establishing an OMAG model for a system S begins by defining a first version of set A i.e. by defining the set of space, shape and time data with approximate values. Then designer selects what are the appropriate Phases and Operating Modes. Indeed, those proposed by default (see Figure 1) can be selected by the de- signer or conversely may be rejected considering they are irrelevant regarding the mission, objectives, requirements, and context of S. If an Operating Mode O is se- lected: -‐ The set of Transitions allowing to activate O (input transitions T for which the source Operating Mode has been also selected) and to desactivate O (output transitions T’ for which the destination Operating Mode has been also selected) are selected and defined by giving the 6-uplet (source, destination, c,e,d,[op]) which characterizes T.
-‐ Configurations of S reachable in O and Operational Scenarios authored by these configurations can be determined. Then, transitions T’ between Configurations have to be determined by determing the 6-uplet (source, destination, c,e,d,[op]) which characterizes T’ where the firing event e can be linked to one of the proposed Operational Scenarios that can induce a modification of the current configuration.
Obviously, as OMAG, all the possible Configurations that can appear in the Operating Modes and the set of Transitions between Configurations forms a new state model that allows to decompose S from a different point of view, here by refining its possible Configurations whatever may be the Operating Mode on which S is.
Applied to VERECINT system, selected Phases are:
-‐ Deployment: the system is subjected to operations to ensure its storage and deployment onto a site on which its mission can begin. This phase is relevant for VERECINT which is involved in activities such as waiting, preparation, adaptation, training, exercise, or regulatory maintenance.
-‐ Exploitation: the system is ready and deployed in operational conditions. This phase is relevant for VERECINTand means that it can be used by stakeholders, here firemen and experts having to explore and evaluate a crisis site. In order to avoid any interpretation, this phase is split up into three Families as follows:
Operating (O): the system is in nominal condition being able to fulfil its mission in coherence with specified requirements, hypothesis, and planed resources. In this Family, VERECINT fulfils efficiently its mission and exhibits nominal behaviours and configurations.
Maintainance (M): the system undergoes operations to restore the operating conditions due to anticipation, failure diagnosis, request for modification, adaptation, evolution, etc. In this Family, we choose to consider VERECINT in predictive or currative maintainance that may be done eventually on the operational site where the crisis occurs.
Default (DS): the system is in a safe state or degraded operation following order, failure, damage, or more generally to an internal or external interference that may cause damage. In this Family, VERECINT has to check default and to decide what maintenance is requested considering it must continue as possible to fulfil its mission eventually with loss of performance but a loss of security of users cannot be acceptable. -‐ End of life: the system is removed from service being concerned by decommissioning, partial resuse or reprocessing of part of all of its components and subsystems for possible future use. The feedback, uses and special cases of operational scenarios 'lived' by the system are finalized, indexed and stored to feed the design of possible future releases. This phase is also selected for VERECINT. The possible Operating Modes of S and those that are retained by a designer for VERECINT are then the followings:
-‐ D1 - System is ready and waiting for deployment: VERECINT is available but stopped and possibly stored out of operational site, ready and packed to be deployed on site and then exploitable by stakeholders. By hypothesis, D1is defined as the initial Operating Mode of the studied system (graphically denoted by a box with large borders in Appendix) here VERECINT. -‐ D2 - Operational retirement: VERECINT has to be removed from the site and repackaged or prepared to be redeployed afresh on another site.
-‐ D3 - System functions for tests, maintenance, or training out of operational site: VERECINT, although not deployed, is operating, possibly in a degraded or reduced testing environment for functional tests, training, or regulatory service beyond operational site.
-‐ O1 - S is deployed and operational on site: VERECINT is operational on site, ready to fulfill its mission in identified operating environments.
-‐ O2 - Preparing the system to assume its mission in nominal mode: VERECINT requires preparation before it can fully perform its operational mis- sion on site (e.g. preheat, audit checklist usage, etc.).
-‐ O3 - S functions in nominal mode: VERECINT fulfill its mission maximizing its performance on specified operating environment.
-‐ O4 - Preparing S to end normally its mission: VERECINT requires to be prepared before stopping its mission normally so various Operational Scenarios can be expected in O4 for VERECINT e.g. cleaning, decontamining, etc.
-‐ O5 - S functions for tests, regulatory maintenance, or training on operational site: VERECINT functions, possibly in a degraded or reduced functional coverage for testing, training, regulatory maintenance on the operational site where VERECINT is currently deployed.
-‐ DS1 - Stop after a default or a dysfunction: VERECINT has to be put in safety due to an internal dysfunction or a default detected which threatens its own integrity and safety or the integrity and safety of the environment.
-‐ DS2 - Diagnosis for default or failure detection: VERECINT is submitted to tests and procedures (led by itself or by one or more contributors systems) of assessment and diagnosis of failures of its functions and components.
-‐ DS3 - S functions in non-nominal mode: VERECINT suffers the
consequences of an internal failure or external events affecting its operational capabili- ties
but continues to fulfill its mission staying in a range of acceptable values in terms of
risk, performance or respect of some chosen non-functional characteris- tics - safety,
security, survivability, maintainability, interoperability, ... called "- ilitie
-‐ M1 - Diagnosis and corrective maintenance: VERECINT has to undergo operations permitting to restore a specified configuration so that it is able to ensure its operational mission again. -‐ M2 - Diagnosis and Preventive Maintenance: VERECINT has to undergo operations for the replacement, revision or repair of one or more of its components before the dreaded occurrence of a default respecting a maintenance plan.
-‐ M3 - Diagnosis and adaptive maintenance: The system has to undergo operations to adapt, for example due to the possibility of using new technologies to better fulfill its initial operational mission. This includes reengineering activities. This Operating Mode is not relevant for VERECINT so M3 and each input and output Transition of M3 are the graphically identified by a red line has diagrammed in Appendix.
-‐ M4 - Diagnosis and evolutionary maintenance: The system has to undergo operations to make it evolve, for example due to the possibility to extent its functional coverage to respond to new requirements or modify its initial operational mission. This includes also reengineering activities. As for M3, this Operating Mode is not relevant for VERECINT.
-‐ F1 - Retirement: VERECINT has to be taken out of service permanently. -‐ F2 - Dismantling: VERECINT has to be dismantled and its various components and subsystems may be stored, packaged or stored for reuse, conversion, reprocessing.
A set of generic Transitions between Operating Modes is given in Figure 2. These
transitions are quoted as follows: Classic Transitions (Ti, i = 1 to 20), Stop (Si, i = 1
to 3), Application Maintenance (AMJ, j = 1 to 4) End of Maintenance (EMj, j = 1 or
2) or Fault Detection Security (FDS). Only input and output Transi- tions of selected
Operating Modes have to be specified by the designers. For more information, the
reader can find all conditions and events having to be specified for each selectable
Transition in OMAG in
The operational semantic of OMAG is formalized for two reasons. First, it
allows describing without ambiguity how a model OMAG can be interpreted and
executed and then to define and implement OMAG simulation mechanisms.
Second, it allows to formalize what are then expected modeling properties
By definition, OMAG is conform to the Interpreted Sequential Machine (ISM)
described in
Thus, the transition triggering is done in two stages. If the condition c is true and the trigger event e appears (always occurring by default if it is not specified), then the Operating Mode or the Configuration is deactivated. This induces eventually to be able to stop current Operational Scenarios that are associated with this one. It can also require the execution of the so called reconfiguration operational scenario op which describes what the required functions are allowing S going from the current Operating Mode or the current Configuration to the next one. After the delay d (equal to null by default), the targeted Operating Mode or Configuration is activated. In the case of an Operating Mode, a default configuration is de- fined and then, is activated. In the case of the activation of a Configuration, authorized Operational Scenarios are launched and executed. Conversely, any Operational Scenario may induce a modification of Configuration, possibly causing the trigger a new transition between this configuration and the next one.
An abstract and a concrete syntax are under development by using DIAGRAPH
tool box (Pfi
Verification techniques have now to be adapted and tested on complex
examples. The perspective is to enrich these two techniques (Conceptual Graphs and
model checking) by considering extensions proposed by