This position paper presents how the engineering of interactive system may be impacted when these systems are designed to be deployed in safety critical contexts. These domains are specific as they are usually driven by constraining standards defining precisely best practices and mandatory processes to be applied. We thus discuss on how it is possible to take into account these constraints in real-life domains where critical and non-critical components may coexist. Engineering approaches in this context must jointly exploit formal description techniques (for the critical parts) and standard software production techniques (for the non-critical part). More precisely, we will show how Engineering Interactive Systems in these domains impact particularly design and development processes, systems architectural aspects and developers' tasks. In the next section, we present the constraints introduced by the safety critical context on development processes that embed certification activities as well as standards (with a focus on aviation industry). Other domain like space, nuclear or Air Traffic Management propose specific standards with stronger or softer constraints but the overall approach remains the same. The third section presents how software and (more globally) system architectures must encompass specificities of current interactive systems and how they are deeply impacted by their critical nature. The fourth section focuses on the human aspect highlighting the specific need for usable tools to support software and system engineers. Last section concludes the paper and provides directions for future work. When dealing with safety critical systems, it is important to notice that all components of the whole system do not have necessarily the same level of criticality, requiring to carefully identify each of them in the early stages of the development process. In this section we present how this identification of levels of criticality is performed and more precisely how it is handled in civil aviation.
In civil aviation, the criticality level of a system (or component) is classified by means of
five Development Assurance Levels (DAL), introduced in the DO-178C standard [
Development As- Failure condisurance Level tion categories
A B C D E
Description of the failure Failure rate
conditions (failures/hour) Catastrophic cFraaisluhre conditions that may cause a 1E0x-t9re+mfealiylsiamfeprobable Hazardous aoFbnaiilpliuetryrefoohframcsraeanwlcaetr,ogoeorpnreeergdaauttecivetsehetihmpelpaancet 1E0x-t7remely remote Major iFmaipluacret tihsasnighnaizfiacradnotu,sbut has lesser 1R0e-m5ote Minor iFmapilaucrtetihsannoMticaejoabrle, but has lesser 1P0ro-3bable
No safety effect No impact on dependability Any range
The main difference between critical and non-critical software is that a lot of verification activities must be satisfied with independence, thus leading to very expensive software and system development. Identifying accurately the correct level of DAL is thus very important in order to invest adequately development resources (not overspend on low DAL systems and not underspend on critical software).
ARINC specification 661 [
As explained previously, the CS-25 standard [
However, during operations, some of the pilot tasks may involve several aircraft
systems with different DALs. For instance, after perceiving an alarm on the ECAM display
the pilot might decide to decrease flight level. In that case, he will successively use
information displayed by the Flight Warning System (DAL C) and trigger commands using the
Flight Control Unit (DAL A). In order to comply with CS 25 1302 it is thus important to
develop methods and tools capable of ensuring that goals can be reached and tasks can be
performed on systems of various DALs involving different techniques (formal and
nonformal) for their development as presented in [
An important task in processes for critical systems is to ensure that high-level requirements
(HLR) have been explicitly (and in an exhaustive manner) gathered and described.
Beyond, the designs and developments must demonstrate that they take into account each of
these requirement and that such traceability is also part of the certification processes (e.g.
in Air Traffic Management [
Such approach has been proposed by [
The software architecture of an interactive critical system must be able to follow the evolution of systems (input devices, output devices, interaction techniques…). Such an everchanging context makes it very difficult to provide generic approaches to support design, development and deployment. Designers need to go beyond the interactive application design by providing new interaction techniques that encompass new input and output deices which can be very cumbersome to design and evaluate. Developers of these systems are repetitively facing the same issues of new devices integration, software redesign (due to device drivers’ evolution) and above all poor reliability of the resulting system due to the low level of maturity of the various components to integrate. Such constraints are even stronger with high DAL critical components.
As proposed in [
Providing support for process and architecture of complex interactive critical systems requires the tools to cope with three challenges: they must be mature enough to support industrial processes, they must support developers’ tasks, they must support models engineering. 4.1
The Technology Readiness Levels (TRLs), defined in ISO 16290:2013 [
While industrial processes may require specific TRL for their tool support, it is
important to assess the maturity of proposed tools. However, in the field of interactive
software engineering, there is not any communication about the TRL of tools involved in
engineering interactive systems. We know for instance that PetShop [
Several tasks must be performed when producing models during the development of an interactive system: When designing and developing interactive systems, the scope of the modeling activities must be identified in order to determine which elements (related to the interactive system to be developed) will be modeled and which types of models will be used. Then, the user/engineer must analyze the extant system, as well as the needs and requirements for the interactive system to be developed. After this analysis step, the production of the models starts with the editing step. That step produces a first version of models. The verification step is then performed for checking the models in order to ensure that they are complete and consistent. The validation step will then be initiated to check whether the model meets specified needs and requirements.
This editing-verification-validation loop will be performed again until the models are
complete, consistent and meet needs and requirements. When introducing several kinds of
models (e.g. task models and system models), the whole process thus must include the
cross validation of these models in order to check if they are complete and consistent.
While these steps are presented in an abstract way, the tools must be tuned for each
notation in order to best support models engineering. In [
In [
Such approach must be extended to modelling activities. For instance, applying (in that
context too) the seven stages of Norman action theory [
One of the main advantages of this model is that it provides a generic framework for investigating where the main difficulties can occur during system modeling which is a highly demanding task on the engineer’s side. This framework thus provides design rules for environments to support user's activities and reduce their difficulties.
Norman action theory provides a generic framework for investigating where the main difficulties can occur during system modeling activities performed by an engineer. Each engineer task described in the previous section (editing, verification, validation and crosstype validation of models) is a goal that must be accomplished during the development of interactive systems. And for each of these goals, the seven stages of Norman action theory can be used to analyze the low-level activities that the engineer will execute. 5
This position paper has advocated the fact engineering interactive system is far from being a mature domain. This is due to the intrinsic nature of these systems that are directly handled by human beings but also due to the fact that their deployment to critical contexts is more and more of importance.
Some work has been proposed over the years by different research groups of different origins but integration is still needed so that engineers of such systems have processes, notations, languages and tools adapted to their work.
Lastly, interactive systems are currently of very low quality and exhibit defects and failure at a very high rate. This is due to the fact that interaction techniques and interaction technologies are a constant moving target trying to support better users, their needs and their experience. In the future, interactive systems engineering should thus progress at a higher pace than interaction technologies in order, first to catch up will current gap and second to have interactive systems engineers adequately equipped for future challenges.