Modeling of System Properties: research challenges and promising solutions Alfredo Garro
Andrea Tundis
Department of Informatics, Modeling, Electronics and Systems Engineering (DIMES) University of Calabria Rende (CS), Italy Via P. Bucci Cubo 41C, 87036
[email protected]
Department of Informatics, Modeling, Electronics and Systems Engineering (DIMES) University of Calabria Rende (CS), Italy Via P. Bucci Cubo 41C, 87036
[email protected]
Abstract— Modeling of system properties deals with formally expressing constraints and requirements that influence and determine the structure and behavior of a system. System Property Models enable the verification of system properties through real or simulated experiments so as to support their evaluation during system design and their monitoring during system operation. However, several research challenges should be addressed to effectively handle systems properties, ranging from conceptual properties representation to tracing and verification. The paper aims at discussing these main challenges and presenting some promising solutions by focusing on those resulting from recent Systems Engineering research efforts. Keywords— Model-Based Systems Engineering, System Properties Modeling, Binding and Automated Model Composition, Tracing and Verification.
I.
INTRODUCTION
According to the International Council on Systems Engineering (INCOSE) [13], System Life‐cycle Processes foresee four process groups to support Systems Engineering (SE) activities: Technical Processes, Project Processes, Agreement Processes, Organizational Project‐Enabling Processes. All of them rely on the ISO/IEC 15288:2008 – Systems and software engineering standard [14], so as to ensure its usefulness across a wide range of application domains, man‐made systems and products, as well as business and services. Specifically, Technical Processes include stakeholder requirements definition, requirements analysis, architectural design, implementation, integration, verification, transition, validation, operation, maintenance, and disposal [12]. Within this group of processes falls the Modeling of System Properties (MSP) that is recently considered among the major research fields of Systems Engineering [26]. MSP deals with system requirements and constraints from the early stages of the system development process, passing through its release, up to its operational maintenance. The Modeling of System Properties includes important aspects to be cautiously considered and carefully evaluated when systems are being built. Especially, in mission-critical domains, such as power
978-1-4799-1920-8/15/$31.00 ©2015 IEEE
plants, medical appliances, aerospace, and automotive, some properties such as reliability, availability, maintainability, safety and security [19], must be guaranteed and comply to standard specifications and norms to allow the commercial release of the system under consideration. Different ideas exist on the definition of properties, as an example, according to the definition given in [16] a property is an expression that specifies a condition that must hold true at given times and places, whereas in the context of complex systems [18] properties can be thought as behaviors that stem from interaction between the components of an application and their environment. Indeed, properties, which can be associated with real systems and their model, define what the system should guarantee or the validity domain for the behavior of the system. The behavior of a system defines how it is expected to work during operation, whereas properties define what the system should guarantee and what the validity domain of the system behavior is. A more recent perspective, that partially embraces both the above mentioned definitions, is provided in the context of the ITEA 3 - MODRIO (Model Driven Physical Systems Operation) project [15], a European project that aims to define models and methods as well as to extend modelling and simulation languages and tools for cyber-physical systems design, diagnosis and operation assistance. In this context, a property is conceived as a concept that may occur in different phases of a system development process, or even for different purposes, and which subsumes (it is a generalization of) the following concepts: (i) requirement, which is typically employed in design phase in order to support the development of the system/component under consideration. Requirements specify what the users want, at functional level, non-functional level, quality level, performance level, and so on; (ii) assumption, which is a property of a system to be a priory satisfied, so it is expected to be implicitly fulfilled; (iii) guard, which is a property that states the conditions that must be satisfied for a model to be valid. The possibility to express properties in a more formal way, would make them exploitable not only during the design and verification phases of a system development process (the
classical V-model), but also during the operational lifecycle of the system, up to its decommissioning. Indeed, whereas during the V-cycle development stages, properties can be exploited for supporting the building process of a system (such as high level design, detailed design and system decomposition, implementation, verification, validation and deployment), during the operational stages, properties can be employed to monitor and analyze the system behavior working in the real world, in order to take corrective actions in case of abnormal operation, as well as for delivering maintenance services and updates. Unfortunately, the identification, definition and formalization of properties are not trivial activities and can depend significantly on the application domain. In this context, the paper aims at providing an overview on the Properties Modeling fields, by collecting experiences and research efforts and discussing them ranging from the main issues and challenges towards possible promising solutions. The rest of the paper is structured as follows: Section II discusses in detail the main open issues about properties modeling; then some available engineering approaches and promising solutions are described in Section III. Section IV raises a discussion on current research efforts and future perspectives by focusing on the activities conducted in the context of the MODRIO European project. Finally, conclusions are drawn up in Section V. II.
OVERVIEW ON SYSTEMS AND RELATED ASPECTS
The International Council on Systems Engineering (INCOSE) defines a system as a combination of interacting elements organized to achieve one or more stated purposes [12]. So it is an integrated set of elements, subsystems, or assemblies that accomplish a defined objective. These elements include products (hardware, software, firmware), processes, people, information, techniques, facilities, services, and other support elements. Examples of systems are: an Air Transportation System, an Attitude Determination Control System, an On-Board Communication System [4, 7, 10]. As reported in [28], modern systems are characterized by five aspects: (i) Structural, related to the form of system components and their relationships, (ii) Behavioral, related to functions, performance, operations, and reactions to stimuli, (iii) Contextual, related to circumstances in which the system exists and operates, (iv) Temporal, related to dimensions and properties of systems over time, (v) Perceptual, related to stakeholder, preferences, perceptions and cognitive biases. Each of the five aspects can be characterized by specific concepts, constructs and considerations. Because of the rapid and continuous increase of systems complexity due to the combination of heterogeneous entities that might belong to different engineering fields such as mechanical engineering, electrical engineering, telecommunications engineering, control engineering and computer engineering, it is not actually immediate determine a clear boundary of control and responsibility of system components as well as who is in charge of what and what entity is responsible for. Faults in interactions among software and hardware remain a significant cause of system failures. It is necessary to adopt comprehensive approaches to support the
overall system development and provide effective models for representing its main characteristics so that properties of entire systems can be analyzed in order to assure the properly working of the system [12]. Indeed, troubles in specifications are often implicated in many serious failures, and it is clear that there exist difficulties stating exactly what is required. There are many aspects of specification that are not supported by any current techniques or models, and, even where specific techniques exist, there remains a lack of integration to permit a whole specification analysis. Verification by testing is not easily feasible for systems that have to operate in what has been called the ultra-dependable range. Formal verification and model checking are desirable technologies but are limited in their applicability [31]. Thus, comprehensive approaches to properties verification are essential to guarantee engineer's expectations in a wide variety of systems. III.
PROPERTIES MODELING: RESEARCH CHALLENGES
Dealing with system properties involve several Systems Engineering aspects to be considered (including functional behavior, timing behavior, performance characteristics, or internal structure), ranging from the need for reference models able to catch the necessary characteristics to define requirements, constrains and their relationships, to mechanisms to link them not only with the system architecture but also with the system behavior so as to support the verification of system against requirements. Main research challenges can be clustered into the following three main groups: (i) conceptual properties representation, which aims at dealing with properties extraction, representations, management, analysis [16, 18, 27]; (ii) binding and automated model composition, which has to deal with connecting models and provide mechanisms for enabling their composition [2, 29, 30]; (iii) tracing and verification, which aims at monitoring specific properties as well as exploit simulation techniques for supporting and verifying their fulfillment [1, 17, 34]. Figure 1 shows a Systems Engineering V-model extended with operational processes (training, monitoring, maintenance, diagnosis, optimization). As it is shown, the overall model is, furthermore, enriched by associating the above mentioned challenges to the different stages of the process. In the following such research challenges are discussed.
Fig. 1. An extended perspective of the Systems Engineering V-model.
Conceptual Properties Representation. This challenge is strictly related to writing requirements as it is widely discussed in [27] by INCOSE. Indeed, the main scope is neither a discovery nor elicitation but it focus on how to express properties, that has to face with the definition of properties models and the identification of the necessary concepts, able to capture specific characteristics in order to provide/create explicit and formal information, starting from the implicit and informal one that can be imprecise and ambiguous. So, there is the need to understand how to identify system properties and what characteristics must be considered. It is also necessary, to establish/identify the status/level of fulfillment of a property that can envisage: (i) a categorical scale such as excellent, good, mediocre, bad etc., or just a Boolean in case of twovalues (true or false) and so on; (ii) a numeric scale for example through either cardinal numbers or expressed in percentages. Then, it is necessary define rules and adopt best practices and guidelines for moving from an informal or textual representation towards a more formalized model. Furthermore, it is necessary to identify metric for describing the objectives to be verified as well as exploit measures which allow objectively the evaluation of the properties under consideration. Consequently, appropriate approaches to define properties along with the possibility to retrieve information about their status are crucial for the overall development process. During this “exploration phase”, it is important to take into account that properties can be also the result of interactions between components, so there is need to first identify the property and then formalize it. So the value of a property might be not always directly available, but could be the result of a combination of complex measuring operations derived from the mixing of inputs and outputs, eventually coming from multiple components of a system. This is the reason that both specific concepts related to properties, models and methods which allow to represents aspects of systems in a more formal way have to be identified. Binding and Automated Model Composition. It has to deal with not only the possibility to establish matching among different system models such as architectural model, behavioral model, property model etc., but also how to enable their composition and at what level, such as manually or (semi-) automatic [29, 30]; this challenge regards the ability to connect someway different models by establishing relationships among variables and their related values, belonging to different models at different abstraction levels in order to produce and integrated model that might be used to perform testing through real or artificial experiments. Unfortunately, real systems are composed by hundreds components and thousands of variables and connections, as a consequence, building complex systems starting from component models that could be also ad-hoc developed or COTS (Commercial Off-the-Shelf) component, without any modification is a challenge that involves many other tasks, such as: (i) identification of the minimum set of information necessary to enable the model composition by keeping high level decoupling of models, (ii) the definition of the properly allocation level, in order to establish the right abstraction level with respect to the component model to be bound, (iii) definition of approaches for automating the dynamic systems model composition. The objective is to automate as much as possible the binding of the system
variables so as to reduce overhead and human errors. The ideal would be to take a set of models in inputs and to produce a unique model in output by hiding, to the users, details about its integration process. Furthermore, two types of bindings should be considered: (i) binding at instance level, (ii) binding at type level. The binding at the type level is conceptually simpler than that instance, because it often does not consider the operating conditions; in fact, two equal components, and therefore the respective models, may behave differently if they operate in different contexts or environmental conditions such as temperatures, humidity, pressure etc. Moreover, by considering software simulation and programming, it is necessary to distinguish between static and dynamic binding. In particular, static binding occurs before runtime (e.g., at compile-time), whereas dynamic binding occurs during program execution and running. Both binding times have benefits and drawbacks. Static binding is mostly used to generate tailored models according to the requirements that are known at building time. By contrast, dynamic binding allows stakeholders to choose required functionality at runtime, so it is more flexible. Tracing and Verification. This is another important challenge to be faced with. It combines the ability to: (i) describe and follow the life of a property, in both a forward and backward direction, through the whole system life cycle, accomplished with varying degrees of fulfillment [17]; (ii) exploit simulation techniques by benefitting of modern modeldriven simulation tools for automating the verification of system requirements into an integrated framework. Tracing and Verification are two sides of the same coin and an important part of a system development process. Indeed, documenting the life/evolution of a system property and providing bi-directional traceability between various associated requirements as well as other developed artifacts, is truly important. It should enable users to find the origin of each requirement and track every change that is made to it. Verification is the task of determining that the system is built according to its specification. It involves evaluating the system during each life cycle phase to ensure that it meets its properties. It should be possible to identify which component (single component or a set of components) is responsible for violating what requirement. The purpose of the verification activities is to promote: (i) the overall quality of the system under development; (ii) the system understanding; (iii) the ability to manage changes. Thus, tracing and verification are independent procedures that are used together for checking that a product, service, or system meets requirements and specifications and that it fulfills its intended purpose. From this perspective, the increasing system complexity has highlighted the need for integrating this step into a formalized model driven development process, providing dedicated methodologies as well as tools for implementing innovative tracing mechanisms supported by modern verification procedures. Addressing the above mentioned issues is not a trivial task to accomplish; indeed, it requires considerable research efforts as well as the employment and the cooperation of human resources with deep and wide knowledge and skills both in academic and industrial contexts, in different engineering fields and application domains.
IV.
PROPERTIES MODELING: PROMISING SOLUTIONS
As discussed in the previous Section, there are many issues related to properties modeling, ranging from concepts exploration, throughout binding and automated model composition, up to their tracing and verification. For each of these research challenges, some of the most recently proposed solutions are collected and described in the next subsections. A. Conceptual Properties Representation Expressing properties and making them computer readable and computable is the basic step in the context of properties modeling. The employment of model-based approaches is very common, and typically two main kinds of trend to face with conceptual properties representation exist in literature: one based on the definition of user libraries, and the other one on the exploitation of specific modeling languages. In particular, as proposed in [26], the exploitation of a library-based approach is adopted to face with properties modeling representation. The definition and the exploitation of user libraries has the advantages of being ease to use and reusable, even though from the other side it is typically tooldependent and limited to the available functions. In fact, it is necessary to identify a priori what concepts and aspects the library want to catch and models. As an example, in [16] a library is conceived for case studies of a specific domain by identifying ad-hoc evaluation monitoring metrics such as threshold monitoring, operating domain monitoring, rate of change monitoring, accumulation monitoring, oscillation monitoring, monitoring with space and time locators. As a consequence, the modeling of new aspects and their related properties means to extend the library continuously. Another approach is described in [35] where specific properties are conceived for modelling responsibilities. In particular, two types of responsibilities are first identified, safety and liveness, then two groups of properties, safety properties and liveness properties, have been respectively defined in terms of rules. These properties are conceived as invariants, and specifically, liveness properties state that “something good happens,” that is, they describe those states of affairs that an system component must bring about, given certain conditions, whereas, safety properties stating that “nothing bad happens”, that is, an acceptable state of affairs is maintained during the operation of the system. A different perspective is proposed in [1, 33] at language level, that bring the advantages of providing new concepts/keywords that are explicitly devoted to properties modeling and thus high flexibility in the definition of new properties. In particular, a meta-model has been appropriately defined. It describes the basic concepts for the representation of properties of cyber-physical systems. The proposal is centered on the Modelica language [6], and in particular, three different approaches for properties representation in Modelica have been proposed. Finally, specific language extensions for properties modeling are introduced and then implemented and prototyped in OpenModelica (an object-oriented simulation tool Open Source, based on the Modelica language) [25]. This approach enables the definition of system properties regardless of any specific application domain as well as of metrics for their
evaluation. From the other side, there are some disadvantages, such as the need of extending both the Modelica language and the Modelica-based development tools, as well as to manage backward compatibility. A further research effort is described in [23]. It concerns a formal language, called FORM-L (FOrmal Requirement Modeling Language), that allows defining and specifying properties, independently from any specific programming or modeling languages and software tools. This work stems from the conception that formal specification is a way to effectively express properties through a language whose vocabulary, syntax, and semantics are well defined and which has a mathematical foundation [34]. This proposal follows the perspective about properties considered in the context of the MODRIO project; a possible taxonomy of such concepts is sketched in Figure 2.
Fig. 2. A possible taxonomy of system properties.
FORM-L defines specific concepts and related notations, by providing a clear separation of models serving different purposes in the Systems Engineering lifecycle. In particular, the following specific concepts and related constructs are proposed: (i) Conditions that represent expressions or functions that can be evaluated over time and can assume three values: true, false or undefined, as they are based on a 3-valued logic; (ii) Boolean and Arithmetic operators that allow managing and making easier operation on specific data structures; (iii) Continuous and Discrete Time locators that define one or more positions in time and have not any notion of duration but are associated to events: when an event occurs then something can happen as a consequence; (iv) Sliding Windows operators that allow for the evaluation of properties in a time sliding window. As an example of the use of FORM-L to represent system properties, with reference to the Backup Power Supply (BPS) system discussed in [23], the property “when the BPS is under maintenance, it must not be activated”, can be formally represented by using the FORM-L constructs as follow: required property bpsMaintenance = during (operational and BPS.states == maintenance) check not (BPS.active) In the same way, the property: “during heating phases, the maximum recirculated airflow of the aircraft Environmental Control System (ECS) shall not exceed x% (max ratio) of the
hot airflow entering the cabin”, can be represented by using FORM-L as follow: required property maximumECSAirflow = during (operational and ECS.States == heatingPhase) check (Ratio_max=
