Jens Braband
email: jens.braband@siemens.com

What's Security Level got to do with Safety Integrity Level?

Keywords: Railway, IT Security, Safety, Threats, IT Security Requirements, Security Level, Safety Integrity Level

Some recent incidents and analyses have indicated that possibly the vulnerability of IT systems in railway automation has been underestimated so far. Due to several trends, such as the use of commercial IT and communication systems or privatization, the threat potential has increased. This paper discusses the relationship of IT security and functional safety from the perspective of their integrity measures.

Introduction 2 Normative background

In railway automation, an established standard for safety-related communication, EN 50159 [START_REF]EN 50159 Railway applications, Communication, signaling and processing systems -Safety related communication in transmission systems[END_REF] exists. The first version of the standard was elaborated in 2001. It has proven quite successful and is also used in other application areas, e.g. industrial automation. This standard defines threats and countermeasures to ensure safe communication in railway systems. The methods described in the standard are partially able to also protect railway system from intentional attacks, but not completely. Until now, additional organizational and technical measures have been implemented in railway systems, such as separated networks, etc., to achieve a sufficient level of protection.

The functional safety aspects of electronic hardware are covered by EN 50129 [START_REF]EN 50129 Railway applications, Communication, signaling and processing systems -Safety-related electronic systems for signaling[END_REF]. However, IT security issues are taken into account by EN 50129 only as far as they affect safety issues, but, for example, denial-ofservice attacks often do not fall into this category. Questions such as intrusion protection are only covered by a single requirement. However, EN 50129 provides a structure for a safety case which explicitly includes a subsection on protection against unauthorized access (both physical and informational), so it is already a "securityinformed safety case". Other security objectives could also be described in that structure.

On the other hand, industrial standards on information security exist. ISO/IEC 15408 [START_REF]Information technology -Security techniques -Evaluation criteria for IT security[END_REF] provides evaluation criteria for IT security, the so-called Common Criteria. This standard is solely centered on information systems and has, of course, no direct relation to safety systems. IEC 62443 [START_REF]Industrial communication networks -IT security for networks and systems, series of 12 standards (planned)[END_REF], also known as ISA 99, is a set of 12 standards currently elaborated by the Industrial Automation and Control System Security Committee of the International Society for Automation (ISA). This standard is not railway-specific and focuses on industrial control systems. It is dedicated to different hierarchical levels, starting from concepts and going down to components of control systems.

How can the gap between information security standards for general systems and railways be bridged? The bridge is provided by the European Commission Regulation on Common Safety Methods No. 402/2013 [START_REF][END_REF]. This Commission Regulation mentions three different methods to demonstrate that a railway system is sufficiently safe: a) by following existing rules and standards (application of codes of practice), b) by similarity analysis, i.e. showing that the given (railway) system is equivalent to an existing and used one, c) by explicit risk analysis, where risk is assessed explicitly and shown to be acceptable. We assume that, from the process point of view, IT security can be treated just like functional safety, meaning that threats would be treated as particular hazards. Using the approach specified under a) IT security standards may be used in railway systems, but a particular tailoring would have to be performed due to different safety requirements and application conditions. With this approach, a code of practice that is approved in other areas of technology and provides a sufficient level of IT security can be adapted to railways. This ensures a sufficient level of safety.

However, application of the general standards requires tailoring them to the specific needs of a railway system. This is necessary to cover the specific threats associated with railway systems and possible accidents and to take into account specific other risk-reducing measures already present in railway systems, such as the use of specifically trained personnel.

As a basis of our work, the IEC 62443 [START_REF]Industrial communication networks -IT security for networks and systems, series of 12 standards (planned)[END_REF] has been selected, as this standard series seemed to provide the best fit. With this approach, a normative base has been developed by the German standardization committee DKE [START_REF] Din | Electric signaling systems for railways -Part 104: IT Security Guideline based on IEC 62443[END_REF], based on IEC 62443 tailored for railways, considering railway-specific threats and scenarios and yielding a set of IT security requirements. Assessment and certification of such a system can be carried out by independent expert organizations. Safety approval in Germany could then be achieved via the governmental organizations Federal German Railways Office (Eisenbahn-Bundesamt, EBA) for railway aspects and Federal German Office for Security in Information Technology (Bundesamt für Sicherheit in der Informationstechnik, BSI) for IT security aspects.

Basic concepts of IEC 62443

A total of 12 standards or technical specifications is planned in the IEC 62443 series of standards that cover the topic of IT security for automation and control systems for industrial installations entirely and independently. This series of standards adds the topic of IT security to IEC 61508 which is the generic safety standard for programmable control systems. Up to now, though, IEC 61508 and IEC 62443 have only been loosely linked. IEC 62443 addresses four different aspects or levels of IT security:

general aspects such as concepts, terminology and metrics: IEC 62443-1-x -IT security management: IEC 62443-2-x system level: IEC 62443-3-x component level: IEC 62443-4-x Today, however, the parts of IEC 62443 are still at different draft stages. Only a small number of parts such as IEC 62443-3-3 have already been issued as an International Standard (IS) or a Technical Specification (TS). Due to the novelty of the IEC 62443 series in this section, the essential concepts of IEC 62443 will be explained briefly so as to improve understanding of the adaptation and embedding of IT security in compliance with IEC 62443 into EN 50129.

IT security management

An IT security management system (ISMS) shall be established for operation of the system. The aim of an ISMS is to continuously control, monitor, maintain and, wherever necessary, improve IT security. In the case of the ISMS, IEC 62443 is based on the general stipulations of the ISO/IEC 17799 and ISO/IEC 27000 series. It details these general standards by adding specific aspects for safety-related control systems. If an ISMS is already established, it may remain in use. However, the essential principles of the ISMS according to IEC 62443 should be introduced or integrated. In the event of integration into an existing ISMS, the special technical aspects of a safety-related railway system shall be observed. Due to the specific framework, unreflected adoption of the stipulations from IT security does not make sense and in most cases can only be implemented with difficulty. The DKE standard [START_REF] Din | Electric signaling systems for railways -Part 104: IT Security Guideline based on IEC 62443[END_REF] offers a comparison of IT security elements from common standards, and is intended to assist integration.

One key task of ISMS is risk management. This includes the consideration of all functional components of the system together with those that are specific to IT security.

System definition

The system and its architecture are divided into zones and conduits. The same IT security requirements apply within each zone. Every object, e.g. hardware, software or operator (e.g. administrator) shall be assigned to precisely one zone and all connections of a zone shall be identified. A zone can be defined both logically and physically. This approach matches the previous approach for railway signalling systems very well, as has been used as the basis in numerous applications [START_REF] Braband | Towards an IT Security Protection Profile for Safety-related Communication in Railway Automation[END_REF]. Figure 1 shows a simple application of the concept, the connection of two safety zones by a virtual private network (VPN) connection as the conduit.

The conduit would consist of the gateways at its borders and the connection in between whatever the actual network would look like. Strictly speaking management would itself be a zone with conduits connecting it with the gateways.

This example may serve as a blueprint for the connection of zones with similar IT security requirements. If zones with different IT security requirements shall be connected, different types of conduits, e. g. one-way connections or filters have to be applied.

IT security requirements

In IEC 62443, the IT security requirements are grouped into 7 fundamental requirements:

1. identification and authentication control (IAC) 2. use control (UC) 3. system integrity (SI) 4. data confidentiality (DC) 5. restricted data flow (RDF) 6. timely response to events (TRE) 7. resource availability (RA)

Normally, only the issues of integrity, availability and data confidentiality are considered in IT security. However, the fundamental requirements IAC, UC, SI and TRE can be mapped to integrity, RA to availability and DC and RDF to confidentiality. Instead of defining a seven level Evaluation Assurance Level (EAL) as in the Common Criteria, which is to be applied with regard to the IT security requirements, a four stage IT security requirement level is defined. A possible explanation might be that also most safety standards define four levels. But it would lead to quite demanding and sometimes unnecessary requirements if the level would be the same for each of the foundational requirements. For example confidentiality often plays a minor role for safety systems and encryption of all data might lead to complications in testing or maintenance of safety systems. So different levels may be assigned for each of the seven foundational requirements. The SL values for all seven basic areas are then combined in a vector, called the SL vector. Note that this leads theoretically to 16384 possible different SL.

The SL are defined generically in relation to the attacker type against whom they are to offer protection: SL 1 Protection against casual or coincidental violation SL 2

Protection against intentional violation using simple means with few resources, generic skills and a low degree of motivation SL 3

Protection against intentional violation using sophisticated means with moderate resources, IACSspecific skills and a moderate degree of motivation SL 4

Protection against intentional violation using sophisticated means with extended resources, IACSspecific skills and a high degree of motivation Sometimes a SL 0 (No protection) is also defined, but as we argue below, at least for safety-related systems this is not an option and so we do not discuss SL 0 further in this paper.

For one zone, for example, (4, 2, 3, 1, 2, 3, 2) could be defined as an SL vector. Once its vector is defined, IEC 62443-3-3 calls for a complete catalogue of standardised IT security requirements for the object under consideration, e.g. for a zone.

It is necessary to take into account the fact that IEC 62443 defines different types of SL vectors:

• The target SL (SL-T) is the SL vector that results as a requirement from the IT security risk analysis.

•

Achieved SL (SL-A) is the SL vector which is actually achieved in the implementation when all the framework conditions in the specific system are taken into account. • SL capability (SL-C) is the SL vector that the components or the system can reach if configured or integrated correctly, independent of the framework conditions in the specific system.

Relationship of SL and SIL

First, we should recall that, like IEC 61508, EN 50129 defines only four different Safety Integrity Levels (SIL).

A SIL "indicates the required degree of confidence that a system will meet its specified safety functions with respect to systematic failures" [START_REF]EN 50129 Railway applications, Communication, signaling and processing systems -Safety-related electronic systems for signaling[END_REF]. Other target measures are defined with regard to random failures, but for IT security we are only concerned with systematic failure [START_REF] Braband | Probability and Security -Pitfalls and Chances[END_REF].

A first look at EN 50129 reveals that safety systems also have to deal with human errors and foreseeable misuse, which corresponds well to SL 1. For this reason SL 0 is not acceptable for safety-related systems. So we can conclude that for any safety system, even if IT security threats can be effectively ruled out, the basic IT security requirements SL 1=(1,1,1,1,1,1,1) should be fulfilled. So it is an interesting exercise to discuss the SL 1 requirements and evaluate whether these are normally fulfilled by safety systems developed according to EN 50129.

In a first step we take a more general look at the Foundational Requirements (FR). Due to functional safety criteria, not all requirement groups of IEC 62443 in applications for railway signalling systems have the same significance. Only the following requirement groups have direct relevance in the sense of functional safety:

1 unauthorised physical or logical access (IAC) 2 unauthorised use (UC) 3 manipulation of the system (SI) 6 response to events that is not timely (TRE) For example, safety-related applications generally do not impose any requirements on the confidentiality of operational data. Therefore, apart from exceptions such as key management, further requirements for confidentiality can be discarded.

So in order to come up with a manageable number of SL vectors, we may as a first simplification and short hand notation set SL 1 as the default for all FR that are not directly safety-related. And we might work under the assumption that in a first approach all other FR may have the same importance. This would lead to four generic SL profiles: (1,1,1,1,1,1,1), (2,2,2,1,1,2,1), (3,3,3,1,1,3,1) and (4,4,4,1,1,4,1). It is admitted that additional SL profiles are necessary for particular zones or conduits. For example a zone containing a key management centre will deserve more demanding confidentiality requirements leading to another profile. But the idea would be to be able to cope with 5 to 10 profiles instead of 16384 possible combinations.

In a next step, we have discussed all 43 requirements from IEC 62443-3-3 in detail in order to find out, which are covered by EN 50129. According to the analysis in the annex many IT security requirements for SL1 are already adequately covered by railway safety standards or are not relevant to safety. These results are summarised in Table 1. They no longer need to be verified in each individual case for railway signalling applications. This means that for new safety-related systems it would be an advantage to implement all SL1 requirements from IEC 62443 (independent from the SIL) as most of them are already covered by safety standards (and some might not be relevant). In this case also an additional IT security certification for SL1 might be avoided as the requirements could adequately be included in the safety certification.

However a more detailed analysis (see the appendix) shows that starting with SL2 requirements there is no similar relationship with SIL anymore. The reason is that by definition the higher SL levels deal with intentional attacks which have only partially be covered by safety standards such as EN 50159 for communication. So also simple rules like "If you have a SIL x safety system then you must require at least SL x" cannot be justified as the allocation of SL depends also on the overall security architecture, e. g. physical protection, and not on the technical solution alone.

Appendix: Relationship between SL 1 and Functional Safety

This annex reports in detail the result of a comparison between the SL 1 requirements (Security Requirements (SR) in compliance with IEC 62443-3-3 and those of EN 50129, EN 50128 and EN 50159. As SL 1 is only intended to offer protection against unintentional or random attacks, it may be presumed that safety-related systems that have to offer protection against foreseeable misuse and operating errors already fulfil a large proportion of the requirements. For example, EN 50129 also already protects against random errors and unintentional disruptions, similar to EN 50159 for Category 1 and Category 2 against corresponding transmission errors. Further measures are only necessary where unauthorised access cannot be ruled out (Category 3).

At the same time, the difference between SL 1 and SL 2 should be pointed out. Additional requirements that are added for SL2 are printed in italics.

This comparison does not mean that all requirements for SL 1 are already covered in EN 50129. At least the requirements that are normally not fulfilled by safety systems should be adopted as requirements in future. Table 1 gives a list of the requirements which are either covered by the safety standards or are not relevant from a safety point of view.

Ref.

Title

Requirement for SL 1 Fulfilment by safety standards SR 1.1 Identification and authentication of persons

The automation system must have the ability to identify and authenticate all human users (persons). The automation system with its corresponding capabilities must assert the identification and authentication at all interfaces of persons who want to achieve access to the automation system, that would allow them to separate obligations and restrictive assignment of authorisations, in accordance with the applicable IT security guidelines and processes. RE1 The automation system must have the ability to uniquely identify and authenticate all human users. This is required by EN 50129 B.4.6. This standard in particular requires that protective measures have to be taken with regard to -oversights by authorised personnel, and -intentional changes by unauthorised personnel. NB The requirements need not necessarily be technically implemented, but can also be fulfilled by corresponding organisational measures.

SR 1.2 Identification and authentication of software processes and devices

The automation system must have the ability to identify and authenticate all software processes and devices and function units. The automation system with its corresponding capabilities must assert the identification and authentication at all interfaces of software processes and devices that want to achieve access to the automation system, that would allow them to restrictively assign authorisations, in accordance with the applicable IT security guidelines and processes.

Generally, access protection is understood in a wide sense in EN 50129, just like in EN 50159.

SR 1.3 User account management

The automation system must have the ability to manage and administer all user accounts of authorised users, which includes opening new accounts and activating, modifying, blocking and deleting accounts. This is not required explicitly, but is an implicit conclusion from EN 50129 B.4.6.

SR 1.4 Identifier management

The automation system must have the ability to manage identifiers and IDs of different kinds and conditions according to users, groups, roles or different interface types of the automation system. This is not required explicitly, but is an implicit conclusion from EN 50129 B.4.6.

SR 1.5 Authenticator management

The automation system must possess the following capabilities and must implement them: a) initialising the authenticator's content, i.e. the means of confirming a user's identity; b) changing all default authenticators after installation of the automation system; c) changing or renewing all authenticators; and d) protecting all authenticators from an unauthorised disclosure and modification during storage or transmission. This is not required explicitly, but is an implicit conclusion from EN 50129 B.4.6.

SR 1.6 Management of wireless access processes

The automation system must have the ability to identify and authenticate all users communicating by wireless means (persons, software processes and devices).

RE 1 The automation system must have the ability to uniquely identify and authenticate all users communicating by wireless means (persons, software processes and devices).

For SL1, this requirement is contrary to EN 50159 B.1. A radio transmission system would generally be assigned to Category 3 and would need cryptographic protection, i.e. more than SL1. Therefore, this requirement is not relevant for SL1. SR 1.7 Security of authentication by passwords Automation systems that use passwords for authentication must have the ability to enable configuration of password security by means of password length (with a given minimum length) and diversity of characters. This is not required explicitly, but is an implicit conclusion from EN 50129 B.4.6.

SR1.8 PKI certificates

If a public key infrastructure (PKI) is used, the automation system must have the ability to operate such a public key infrastructure in accordance with common conventions or it must be able to obtain public key certificates from an existing public key infrastructure.

Covered in EN 50159 for Category 3 if asymmetrical methods are used.

SR 1.9 Security of asymmetrical crypto systems In automation systems that use asymmetrical crypto systems (public key crypto systems) for authentication, the automation system must have the following capabilities: a) The ability to validate certificates by checking the validity of a given certificate's signature b) The ability to validate certificates by building up a certification path to a recognised certification agency (CA) or, in the case of a selfsigned certificate, by issuing mutual confirmations to all hosts that communicate with the key holder for whom the certificate was issued c) Checking certificates to determine whether they are on a certificate blacklist (or a revocation list) d) Bringing about secure storage and monitoring of the associated private key by the user (person, software process or device) e) The ability to map the authenticated identity to a user (person, software process or device)

Addresses in EN 50159 for Category 3 if asymmetrical methods are used, but not in relation to all details. SR 1.10 Feedback from the authenticator

The automation system must have the ability to suppress (blacken) feedback messages generated by the authenticator during the authentication process. This is not explicitly required, but is easy to realise. SR 1.11

Failed login attempts

The automation system must have the ability to assert a limit to the number of failed successive login attempts (person, software process or device) within a configurable time. The automation system must have the ability to block physical or logical access for a specified time or it must allow an administrator to lift this block again after this time had been exceeded.

For system accounts on whose behalf critical services or servers are operated, the automation system must provide for the ability to forbid interactive logins. This is not explicitly required, but is easy to realise. SR 1.12

Reference to system use

The authentication system must have the ability to refer, even before authentication, to the rights and obligations linked with use of the system. A 'System Use Notification' is displayed for this purpose. It must be possible for authorised personnel to configure this display. This is not explicitly required, but is easy to realise if wished by the operator.

SR 1.13

Access through untrustworthy networks

The automation system must have the ability to monitor and control all kinds of access to the automation system through untrustworthy networks. RE1 The automation system must have the ability to deny access through unreliable networks, but the desire is approved by an instance authorised to do this.

In SL1, only Category 1 and 2 networks come into consideration. In 1 there are only known users, i.e. the requirement is unnecessary. In Category 2, although the users are not all known, they are trustworthy.

SR 2.1 Enforcing authorisation

At all interfaces, the automation system must ensure enforcement of the authorisations assigned to all human users; as a result, these persons become authorised and are enabled to control the automation system in such a way that separation of duties and restrictive authorisation assignment can also be asserted. RE 1 At all interfaces, the automation system must ensure enforcement of the authorisations assigned to all users (persons, software processes or devices); as a result, these users become authorised and are enabled to control the automation system in such a way that separation of duties and restrictive authorisation assignment can also be asserted.

RE 2 The automation system must possess the ability and must make it possible for an authorised user or an authorised role to define and modify mapping of the authorisations of all human users to roles.

This is derived from EN 50129 B.4.6.

SR 2.2 Use control and monitoring in the case of radio connections

In the case of radio (wireless) connections into the automation system, the automation system must possess the ability to authorise, monitor and also fulfil restricted use in accordance with the security conventions that are generally common in industrial practice.

This requirement is contrary to EN 50159 B.1. A radio transmission system would generally be assigned to Category 3 and would need cryptographic protection, i.e. more than SL1. SR 2.3 Use control and monitoring in the case of portable and mobile devices

The automation system must possess the ability to automatically implement and execute configurable restrictions of use: a) Preventing use of portable and mobile devices b) Demanding a context-specific authorisation c) Restricting transmission of data and code from and to portable and mobile devices

In EN 50129, mobile devices are treated just like other devices if they perform fail-safe tasks. The specific requirements must be derived from a hazard analysis, however.

SR 2.4 Mobile code

If mobile code techniques are used, the automation system must be able to assert restricted use, taking into account the damage that can possibly be caused in the automation system. These abilities include: a) Preventing execution of mobile code b) Demanding clean authentication and authorisation of the code source c) Limiting transfer of mobile code to and from the automation system d) Monitoring the use of mobile code Mobile code is not allowed in safetyrelated systems because it is not covered by validation and approval.

SR 2.5 Session blocking

The automation system must possess the ability to prevent further access to the system by blocking the session after an adjustable inactivity time or by manual intervention. The session must remain blocked until the session owner or another authorised person restores access by again initiating the identification and authentication process intended for this purpose. This is not explicitly required, but is easy to realise.

SR 2.6 Ending a remote session

The automation system must possess the ability to end a remote session either automatically after an adjustable period of inactivity or it must make it possible for the session to be ended manually by the user who initiated it. This is not explicitly required, but is easy to realise. SR 2.8 Verifiable events and their recording

The automation system must possess the ability to generate audit data (data recorded during computer and network monitoring, information technology measurements) concerning the IT security achieved in the following categories and to record such data as audit records: access control, flawed queries, incidents in the operating system, incidents in the automation system, incidents during backup and recovery of data, potential reconnaissance and incidents during audit report creation. The individual audit reports must contain the following information: Time of the incident, incident source (designation of the device, equipment, software process or user account in which the incident is taking place or has taken), category, type, incident number and result.

Although data logging is a common practice, it is not required normatively because such data is generally not considered to be relevant to safety. SR 2.9 Storage capacity for audit records

The automation system must provide adequate storage capacity for storing audit records in accordance with generally recognised recommendations for log management (archiving of incident logs) and system configuration. The automation system must ensure that not too much storage capacity is maintained.

See above.

SR 2.10

Response to failed audit data processing

If it should transpire that the audit data (data recorded during computer and network monitoring, measured results regarding information technology processes in IACS) is no longer processed at all or no longer correctly, the automation system must possess the ability to inform operating personnel of this and it must prevent the loss of essential services and functions. As a response to failed processing of audit data, the automation system must possess the ability to initiate suitable remedies in accordance with generally recognised industrial conventions and to support them.

See above.

SR 2.11 Time stamp

The automation system must assign a time stamp to the audit records generated.

As detailed in EN 50159, time stamps can be used, but are not required. SR 3.1 Communication integrity

The automation system must possess the ability to preserve the integrity of information transferred.

Protecting the integrity of the message s t r e a m i s a b a s i c r e q u i r e m e n t o f E N 50159. SR 3.2 Protection against harmful code

The automation system must possess the ability to take precautions against harmful code or unauthorised software; corresponding mechanisms should detect and report such harmful code and should defuse any negative impacts. These protective mechanisms must be updated.

RE 1 The automation system must possess the ability to use processes for protection against harmful code at all entry and exit points.

In SL1, IEC 62443 assumes untargeted attacks, the viruses, etc. are not specifically directed at the system.

EN 50128 15.4.6 requires protection of software against unintentional or random modification and this suffices for SL1. SR 3.3 Verification of IT security functionality

The automation system must possess the ability to verify the intended operation of the IT security functions and must report whenever anomalies are detected during factory acceptance testing (FAT), during site acceptance testing (SAT) and during a scheduled maintenance operation. These security functions must comprise all functions that are needed to fulfil the information technology security requirements defined in this standard.

I n t h e c as e o f s af e t y s y s t e m s , t h i s requirement is covered by validation in compliance with EN 50128.

SR 3.4 Software and information integrity

The automation system must possess the ability to detect, record, report and protect against unauthorised changes to software and stored inactive or archived data.

EN 50128 13 requires protection of software against unintentional or random modification. SR 3.5 Input validation

The automation system must validate the syntax and the contents of indirect inputs into an industrial process control system and of direct inputs with direct impacts on the automation system. P l a u s i b i l i t y c h e c ks a r e re q u i re d b y E N 50129 E.5.1 and also by the principle of defensive programming in EN 50128. SR 3.6 Deterministic output

The automation system must possess the ability set outputs to a predetermined status if no normal operation can be maintained any more as a result of an attack.

In accordance with EN 50129 B3.4, a safe status must be assumed in the event of a fault, including avoidance of unsafe outputs. SR 3.7 Error handling The automation system must detect errors and must handle error states in such a way that an effective remedy is possible. At the same time, steps must be taken to ensure that no information is disclosed that can be used by enemies to attack the IACS unless the disclosure of this information is indispensable to remedy the problems in good time.

EN 50129 and EN 50159 do not contain any specific requirements in this respect.

SR 3.8 Session integrity

The automation system must possess the ability to preserve the integrity of sessions. The automation system must reject use of invalid session identifiers (IDs). This is required in EN 50159.

SR 3.9 Protection of audit information

The automation system must protect verified and recorded incidents (audit information) and audit tools (insofar as available) against unauthorised access, modification and deletion.

EN 50129 and EN 50159 do not contain any specific requirements in this respect.

SR 4.1 Confidentiality of information

The automation system must possess the ability to preserve the confidentiality of information for which a read authorisation is expressly required, be it in transit or in the idle state. RE 1 The automation system must possess the ability to preserve the confidentiality of information or data that is in the idle state and protect data that is routed through an untrustworthy network during a remote session.

Confidentiality is not normally required for railway applications. Processes that are not safety-related may also access information.

SR 4.2 Information constancy

The automation system must possess the ability to permanently delete all information on data media for which a read authorisation was expressly required and which are to be taken out of operation or shut down.

EN 50129 and EN 50159 do not contain any specific requirements in this respect.

SR 4.3 Using encryption

If encryption is required, the automation system must use cryptographic algorithms for the size, the mechanisms of key creation and management of keys in accordance with the security conventions and recommendations generally recognised in information technology. The automation system must possess the ability to monitor communications at zone boundaries and to intervene, if necessary, to be able to execute the departments defined in the risk-based zone and conduit model. RE 1 The automation system must possess the ability to always reject network traffic and to permit it only in exceptional cases.

Only Category 1 and Category 2 networks may be used for SL1. These form a single zone with uniform IT security requirements and so no splitting is necessary and this requirement does not make sense for SL1.

SR 5.3 Restriction of general communication between persons

The automation system must possess the ability to prevent exchange of messages between persons that are sent by users or systems outside the control system and are received by persons inside the control system.

Generally, voice communication is not part of the safety system. However, this requirement should be exported to the operator.

SR 5.4 Partitioning applications

The automation system must possess the ability to partition data, applications and services depending on the complexity of the zone model to be realised. The automation system must possess the ability to continue working in a restricted mode of operation during a DoS attack. RE 1 The automation system must possess the ability to control the traffic load (for example by limiting the data transfer rate) so that the impact of a provoked inundation with data leading to triggering of a reduced availability can be mitigated.

This requirement is normally not contained in safety standards. In railway, however, there is normally a fallback level after failure of technology. In future, IT security aspects may have to be considered in the design of the fallback level.

SR 7.2 Resource management

The automation system must possess the ability to counteract exhaustion of resources; to this end, security functions would possibly have to be granted fewer resources.

This requirement is normally not contained in safety standards. SR 7.3 Backups of the automation system

The automation system must be capable of storing and archiving backup copies (backup) of critical files and data from the user and the system levels (including information about system status) in a secure location without detrimentally influencing ongoing operation of the system. RE 1 The automation system must possess the ability to check the operability (reliability) of backup mechanisms.

This requirement is normally not contained in safety standards. SR 7.4 Restart and recovery of the automation system

The automation system must possess the ability to restart after an interruption or a failure and to return to a known secure state. This is required in EN 50129 B5.2. SR 7.5 Emergency power supply

The automation system must possess the ability to switch to an emergency power source, or to return to a normal supply source from it, without exerting any detrimental impact on the existing security state or a documented restricted mode of the IACS.

This requirement is normally not contained in safety standards.

SR 7.6 Network and security settings

The automation system must possess the ability to be configured as provided for in the instructions included by the supplier of the automation system; this applies in particular to recommended network and security settings. The automation system must provide an interface to the current network and security settings.

EN 50129 or EN 50128 requires configuration management as part of quality management. The requirements for configuration are part of the safety application conditions. SR 7.7 Restrictive functionality assignment

The automation system must possess the ability to specifically suppress the application and use of unnecessary functions, ports, protocols or services or at least to restrict these applications.

EN 50128 requires complete tests. Railway software may only contain (activated) functions that are required in accordance with the specification. EN 50128, Section 7.3.4.7 can be referenced with regard to pre-existing software. Nevertheless, the result in certain circumstances for COTS components such as a switch is that certain functions are deactivated. SR 7.8 List of the automation system's components

The automation system must possess the ability to issue a list of all currently installed components of the automation system with the relevant characteristics and features.

This requirement is normally not contained in safety standards.

Figure 1 :

 1 Figure 1: Zone and conduit architecture example

Table 1 -

 1 IT security requirements that are already covered or are irrelevant

	Reference	Title	Assessment
		Management of wireless access	This requirement is not relevant for SL1.
	SR 1.6	processes
		Access through untrustworthy	This requirement is not relevant for SL1.
	SR 1.13	networks
		Use control in the case of radio	This requirement is not relevant for SL1.
	SR 2.2	connections
		Communication integrity	This requirement is fulfilled by application of EN 50159.
	SR 3.1
		Verification of IT security func-	This requirement is fulfilled by application of EN 50128.
	SR 3.3	tionality
		Software and information integ-	This requirement is fulfilled by application of EN 50128.
	SR 3.4	rity
		Input validation	This requirement is fulfilled by application of EN 50129 and EN 50128.
	SR 3.5
		Deterministic output	This requirement is fulfilled by application of EN 50129 and EN 50128.
	SR 3.6
		Confidentiality of information	This requirement is not relevant for railway applications with SL1.
	SR 4.1
		Use encryption	This requirement is not relevant for railway applications with SL1.
	SR 4.3
		Network segmentation	This requirement is fulfilled by application of EN 50159.
	SR 5.1
		Protection of the zone boundary	This requirement is not relevant for SL1.
	SR 5.2
		Restriction of general commu-	Generally, voice communication is not part of the safety system. However, this
	SR 5.3	nication between persons	requirement shall be exported to the operator.
		Protection against DoS attacks	This requirement is normally not contained in safety standards because it cannot
	SR 7.1		be fulfilled by safety-related systems alone. The rule shall be exported to the
			operator.
		Resource management	This requirement is normally not contained in safety standards because it cannot
	SR 7.2		be fulfilled by safety-related systems alone. The rule shall be exported to the
			operator.
		Backups of the automation sys-	This requirement is normally not contained in safety standards because it cannot
	SR 7.3	tem	be fulfilled by safety-related systems alone. The rule shall be exported.
		Restart and recovery of the	This requirement is fulfilled by application of EN 50129.
	SR 7.4	automation system
		Emergency power supply	This requirement is normally not contained in safety standards because it cannot
	SR 7.5		be fulfilled by safety-related systems alone. The rule shall be exported to the
			operator.
		Network and security settings	This requirement is fulfilled by application of EN 50128 and EN 50129.
	SR 7.6

Summary

This paper has discussed the relation between SL from IEC 62443 and SIL from EN 50129 for safety systems. The major new results are:

• SL and SIL are completely different concepts, e. g. SL is a seven dimensional vector in contrast to the scalar SIL • There is no simple relationship between SL and SIL • SL 0 for safety-related systems is not acceptable. For safety systems, it is recommended to always take the requirements of SL 1 into account • A preliminary proposal for SL profiles has been made in order to master the complexity of potentially 16384 SL vectors Table 1 gives a summary of which requirements for SL 1 are already covered or not relevant from a safety perspective. The annex gives a more detailed discussion including a comparison with SL2 requirements. The results should also hold for other related safety standards such as IEC 61508 as they build upon similar general principles, however the details would have to be checked and might differ.


Emmanuel Gaudin
email: emmanuel.gaudin@pragmadev.com

Asynchronous modeling in railway systems

Keywords: Modeling, Asynchronous, Synchronous, Matlab, Lustre, SDL, TTCN3, Railways, ERTMS

Models in the railway industry are often based on synchronous technologies such as Matlab or Scade. This is due to technical reasons, but because of its concepts the abstraction level of synchronous models are very low and very close to the implementation level. A serious gap is observed between the requirements described in natural textual language and the model which is basically an implementation. The increasing level of system complexity, combining communicating subsystems, calls for a more abstract model. This paper will first discuss why synchronous technologies have been used in this type of systems, then an experiment of using an asynchronous technologies on a real ERTMS case coming from SNCF is described, and finally the paper will conclude on how an asynchronous modeling technologies could make the link between the informal textual requirements and the implementation of the system.

Introduction

When it comes to modeling two main questions have to be addressed. The first one is about positioning the model in the development cycle ; defining if the model is a requirement, a specification, or a design. The second one is about the modeling technology to use ; depending on what the model is aiming at. The lower is the model level, the more specialized is the modeling technology, and the narrower is the scope of the model. In [START_REF] Flammini | Railway Safety, Reliability, and Security: Technologies and Systems Engineering[END_REF] the technologies usually applied to model train systems are listed such as the B method, Scade, Simulink/Stateflow. In [START_REF] Liu | A Calculus for Hybrid CSP[END_REF] and [START_REF] Cimatti | Formal Verification and Validation of ERTMS Industrial Railway Train Spacing System[END_REF] the authors present how they have written a specific type of model in order to verify specific safety properties. The models are usually dedicated to the targeted model checking technology and can not be used for anything else. In [START_REF] Callet | The Use of a "ModelBased Design" Approach on an ERTMS Level 2 Ground System[END_REF] is presented the work done by SNCF to verify safety rules using The Mathworks tools. In [START_REF] Sergent | SCADE A comprehensive framework for critical system and software engineering[END_REF] the author presents a tool that makes a link between a system level model written with Papyrus SysML modeler and a design level model written with SCADE Suite. In [6], following the ASSERT FP6 european project, the European Space Agency has been promoting the TASTE (The ASSERT Set of Tools for Engineering) framework. Because each technology is best suited for a part of the overall system, TASTE framework aims at gathering the different technologies in a consistent framework. The top level model is an architecture model based on AADL and ASN.1. The different AADL architecture blocks are further developed with a dedicated technology such as Scade or SDL. When all models are validated a code generator automatically gathers the code generated by the different tools.

In the above references, the choice of the modeling language is often driven by the possible verification associated to the technology. For that purpose models are based on low level modeling technologies that are very close to the implementation details. Attempts to raise up the modeling level have been done using a combination of languages. For that purpose the synchronous or asynchronous approaches are put at the same level and a third language is used as an overall model view (SysML or AADL). In this paper we are experimenting a different approach in which an asynchronous SDL model is used as a bridge between the requirements and a low level synchronous model. To demonstrate this, an existing Matlab model is taken as an example and translated to an SDL model. Using an SDL simulator and solver the system functions are then analyzed. Finally there will be a discussion on what the SDL model brings to a Matlab model.

A natural synchronous approach

In the old days, train systems were exchanging simple information such as "is the train present on that portion of track" , "are the doors open or not". These information can be detected with simple electrical detectors along the tracks, on the platforms, or in the train itself. These detectors behave like electrical switches and the information can be extracted from the fact that the circuit is open or closed. From a software point of view, all this information can be represented by binary variables. The rationale is a logical combination of the different information gathered. It would be something like "if the train is not stopped at the platform, then the doors should be closed". And this information would be verified every time some new information was received from the sensors. Each clock tick, the information from the sensors is gathered and given to a logical system that will compute all the entries and produce some outputs. That is the basic principle of a synchronous approach. All the entries are valid at the same time, some logical operators combine the inputs taking into consideration the previous values of the inputs, and produces some outputs. Each clock tick, the whole information is computed again and again. The fact that the system recomputes everything at every clock tick actually reduces the possible number of cases that might occur in the system. It is therefore much easier to verify properties at each clock tick and make sure the system behaves properly whatever happens, whatever the information read by the sensors.

New approach for upcoming systems

Train management systems are evolving, and in particular the European Rail Traffic Management System (ERTMS [START_REF]European Rail Traffic Management System ERTMS[END_REF]), which was initiated in the 90's by the European Union, aims at harmonizing and expanding the capabilities of train control systems over Europe so that a train crossing borders does not need a specific controller for each country it crosses. This standard covers specification of on board equipments, on the trackside equipments, as well as communication information systems. The information exchanged includes speed, acceleration and so on. It is more and more complex and is getting quite far from the original binary information. Furthermore all the equipments are not mechanically or electrically connected, they are now completely desynchronized from one another. The information is not that simple any more, it is complex and unpredictable. Using synchronous technologies might work on a local level but will definitely not be sufficient to describe new features that combine a lot of communication. In fact the higher is the level of the view, the less a synchronous description will fit. This is a known issue in systems where complexity is increasing. It has been theorized and discussed in several publication as the GALS (Globally Asynchronous Locally Synchronous [START_REF]Globally asynchronous locally synchronous[END_REF]) theory of system description since the 80s. At that time, asynchronous descriptions were transformed to synchronous descriptions based on the theory that asynchronous models could be deconstructed to synchronous models and reconstructed back [START_REF] Benveniste | From synchrony to asynchrony[END_REF]. The point was to be able to use the existing and mature synchronous validation and verification technologies on the market at that time [START_REF] Mousavi | Modeling and validating globally asynchronous design in synchronous frameworks[END_REF]. This works as long as the model is close to the implementation. This is not satisfying any more in complex communicating systems as the first thing to do when developing a new feature in a system is to verify its functionality before trying to implement it. That raises the need for asynchronous descriptions and verification techniques.

An asynchronous description of existing models

On one side the higher the abstraction level is, the more asynchronous are the relations among the elements in the system. On the other side in order to produce a relevant and verifiable dynamic description, the model needs to be executable. That means it should be statically and dynamically unambiguous from a semantic point of view. SDL [6] international standard that was initially designed to describe telecommunication protocols is a good candidate for this type of description. It is by nature asynchronous, it combines graphical views for architecture and state machines, and includes an action language with simple data types to describe a detailed behavior whenever needed in the description.

Figure 1: A basic SDL architecture

Figure 1 shows an SDL architecture with two blocks. Each block can be further decomposed in subblocks. At the lower level of the architecture one or several finite state machines describe the behavior of its container. The flow of information between the blocks is message based. Each state machine has its own implicit FIFO message queue.There is no clock based inputs in an SDL system. Only the sequence of events matters.

Figure 2: A simple SDL state machine

Figure 2 shows a simple SDL state machine. In the administration state, the state machine will read its message queue. If addUser message is received the instructions below the addUser input symbol are executed, an accepted message is sent to the sender of the addUser message, and the transition ends back in the idle state. If message deleteUser is received, the counter internal variable is set to 0, and the transition ends also in the idle state.

The different state machines in an SDL model run in parallel. The main issue with this type of description is verification. Because of its asynchronous nature, events can occur at any time, independently from each other, and this creates a huge number of possible scenarios. Model checking tools can explore the possible combinations, but the number of cases is sometimes very difficult to handle making verification of properties on this type of system a real challenge. Since this type of description is well suited for a high level description it is naturally close to a functional description or a high level requirement. It is therefore quite interesting to analyze how the requirements could be translated into an asynchronous model and a synchronous model, and see if one could be translated to the other. This is what was done on a Radio Block Center from the ERTMS [START_REF]European Rail Traffic Management System ERTMS[END_REF]. Figure 3 and2 show the architecture level using Matlab and using SDL. Even though both model contain the same blocks the main difference is the communication semantic. Information exchange is synchronous in Matlab and message based in SDL. 5 indicates the description of the block is done with a state machine. It lists all the inputs and outputs of the state machine. This is not necessary in SDL as a process behavior is always described with a state machine.

Figure 5 : Connect and disconnect block is made of one synchronous state machine

The Matlab state machine is described in Figure 6 and the SDL equivalent state machine is described in Figure 7. In the example described in Figure 6 & 7 the inputs are very similar. For example reception of msg155 event is done setting the boolean variable msg155_recu to true in Matlab, while it uses the message input symbol in SDL. The Matlab representation forces the modeler to make sure msg155_recu is set to false after being received because if not it might be taken into consideration again in another transition. Similarly to output some information from the state machine, the Matlab model sets boolean values to true or false. For example in the Session_etablie state, envoi_msg32 is set to true when entering the state, then set to false while in the state, and again set to false when exiting the state. In an event based language such as SDL, there is only one msg32 output when msg155 is received and that's it. In that sense it makes things much clearer.

The other example below, Deconnecter_selon_mode in Figure 8 & 9, shows how to disconnect the train depending on the mode in which it is. In that example the main difference is on the inputs of the state machine. The Matlab model uses logical operators AND and OR to identify which input was received; the SDL model is just a list of inputs, and the star means any other input.

In both examples the model is equivalent from a functional point of view, depending on the reader's technical background one or the other might be easier to read and understand.

Model verification

The experiment included some simulation of the SDL model with small prototyping graphical user interface in order to verify the behavior was correct. Once the model was considered correct, PragmaDev symbolic resolution tool, result of PragmaList [START_REF] Gaudin | ModelBased Testing: An Approach with SDL/RTDS and DIVERSITY[END_REF][9] common lab, has been experimented on the model. This technology combines the transitions from a symbolic point of view, and tries to solve each possible combination like it would do with an equation. If there is a solution to the equation the path is possible. The first objective with that technology was to automatically generate the minimum number of test cases with a maximum coverage. After a few trials the tool could not reach two transitions in the model. A manual analysis rapidly concluded this use case did not allow one of the generic functions in the model to return the values required to reach these two transitions. Once this was settled test generation out of the model was successfully experimented and 17 test cases covering all transitions were automatically generated. Five properties have been written to be verified on the model. As for the experiment, the properties were actual pieces of the state machine written with another language. For example the first property verifies that when in state Connexion_en_cours, when receiving msg159 the state machine goes to state Etablie and not any other. The symbolic resolution tool has been ran on the model with its properties for a few hours reaching a substantial depth of search, meaning a substantial number of transition combination. As a result, within this exploration perimeter the properties were satisfied.

How to link asynchronous models to synchronous models

During the experiment it has been established the SDL model was further away from the implementation than the Matlab one. Because of its asynchronous principles it was more of a functional view of the behavior and therefore closer to the requirements. This clearly validated the idea of having a high level asynchronous executable functional model to make sure the requirements are properly understood. The question was how to link this asynchronous approach to a synchronous one. It turned out an asynchronous model, including a test case, can easily be connected to a synchronous one. For example a synchronous input can be evaluated at each tick and when the value of the input changes it generates an asynchronous message (Figure 10). On the other way around an asynchronous message output can be converted to a clock based value.

Figure 10: An synchronous change of value can be transformed to an asynchronous send

This shows that it would be possible to generate code out of the asynchronous model and connect to a synchronous target, or to generate test cases out of the asynchronous model and run them against a synchronous implementation in order to check it is conform to the model.

Conclusion & Future work

The experiment on this real use case in the railway domain has demonstrated that an SDL executable asynchronous model could be functionally equivalent to a Matlab synchronous model. Because of its asynchronous nature the SDL model is closer to the requirements, where a Matlab model is closer to the implementation. An SDL model could therefore be used by stakeholders early in the development process to formalize requirements and to verify them from a functional point of view. A Matlab model would still be used later on for the implementation. And the SDL model would be the reference to verify functional properties, or to generate test cases to verify the final implementation is functionally conform to the initial requirements.

Bibliography

Figure 3 :Figure 4

 34 Figure 3: Architecture described with Matlab

Figure 6 :

 6 Figure 6 : Matlab synchronous state machine

Figure 8 "

 8 Figure 8 "Disconnect depending on the mode" Matlab state machine


Julien Delange
email: jdelange@sei.cmu.edu

Peter Feiler

Neil Ernst
email: nernst@sei.cmu.edu

Incremental Life Cycle Assurance of Safety-Critical Systems

Finding problems and optimal designs in the requirements phase is more efficient than later phases. However, over-constraining the solution is also sub-optimal since not all information is necessarily available upfront. 'Build-then-test' approaches which insist on developing first requirements, then architecture, then implementation are not suitable for building systems that must be rapidly fielded and respond to ever-changing demands. Our approach, ALISA, is working on integrating four pillars for incrementally building systems which can be shown to satisfy the relevant requirements. Our four key pillars for assuring requirements satisfaction are requirements specifications, architecture models, verification techniques, and assurance case traceability between the first three. In this paper we introduce our approach, and highlight how we are integrating these pillars using an XText-driven DSL and tool meta-model leveraging existing tools and languages. Our current focus is on understanding exactly which requirements are responsible for the majority of design constraints. Identifying this subset promises to reduce architecture design space exploration and verification overhead, increasing delivery cadence.

I. INTRODUCTION

Safety-critical systems function where an error can be mission-or life-threatening. They are carefully specified and designed according to a rigorous process, usually by different collaborating teams. Through the development process, system stakeholders define their goals, engineers define system requirements from them, and architects design the architecture, breaking the system into several layers and parts. Each part/layer is implemented by potentially different teams, tested separately and then integrated. One major issue of this actual process is the late discovery of errors: 80% of implementation errors are found at system integration but studies have shown that such issues (70% actually, shown in Fig. 1) are likely introduced earlier, when defining the system requirements. Thus, these errors could be discovered and fixed earlier, by improving requirements specification and design.

In this paper, we introduce our approach for improving requirements specification and design, called Architecture-Led Incremental System Assurance, ALISA. Our approach is traceable and testable from end to end, that is, from system requirements and stakeholders, down to software and verification outputs. This new method connects requirements to other system artifacts (specifications, models, code, etc.), enabling requirements traceability and validation along the development To improve the quality of requirements we focus on coverage of system specifications, quality attributes, and hazards, as well as management of uncertainty in the requirements. To improve the quality of evidence we use compositional verification, and multi-valued logic to automate the planning, execution of verification plans, and management, reporting of assurance evidence. In order to so we work with three different flavors of incrementality:

1) incrementality by refinement, working with one architecture layer or module at a time 2) incrementality by criticality, focusing on critical requirements/quality attributes first, and then the full set 3) incrementality by change impact, to manage the impact of changes on requirements, architecture design, and verification evidence.

II. RELATED WORK Moving from requirements to architecture is a key problem in software engineering. Current standards [START_REF]Iso 15288 systems engineering-system life cycle processes[END_REF], [START_REF] Singh | International standard iso/iec 12207 software life cycle processes[END_REF] describe the life-cycle process to follow in order to develop software but consistency between development phases is often not synchronized, performed using a manual, labor-intensive process and consistency between each phase is not automated, and becomes out of date as products evolve.

One important issue has been to identify architecturallysignificant requirements from a requirements specification; that is, those requirements which will have the most impact on how the system is implemented. For example, a well-developed methodology for this is the Quality Attribute Workshop [START_REF] Barbacci | Quality attribute workshops (QAW)[END_REF] and design approaches such as the Architecture-Driven Design (ADD) approach. Seminal work includes moving from goals to agent-oriented software, with Tropos [START_REF] Giorgini | TROPOS: An Agent-Oriented Software Development Methodology[END_REF]; moving from KAOS specifications to software in [START_REF] Van Lamsweerde | From system goals to software architecture[END_REF]; and work by Dewayne Perry and his students [START_REF] Brandozzi | From goal-oriented requirements to architectural prescriptions: The Preskriptor process[END_REF]. One key advance is that there now exist many mature languages for both requirements (e.g., KAOS [START_REF] Dardenne | Goal-directed requirements acquisition[END_REF] and the URN standard [START_REF]International Telecommunication Union. User requirements notation (urn)[END_REF]) and architectures (e.g., AADL [START_REF] Aerospace | Architecture Analysis and Design Language[END_REF] and SysML [START_REF] Omg | Systems Modeling Language[END_REF]). This allows us to leverage well-known formalisms for the translation. Furthermore, while there were hints in earlier work towards refinement, there was no explicit step for driving evidence-based changes in the requirements, as we propose in ALISA.

In the iterative context, requirements are ideally 'conversation starters' for design elaboration. For example, one takes the provided user story and queries the product owner about any uncertainties. And in an iterative context, particularly with iterations of 2-4 week duration, one can fairly easily refine these requirements. This approach does not work in all contexts, however, and may be guilty of finding local optima (e.g., under-designing), particularly in more complex systems [START_REF] Ernst | Case Studies in Just-In-Time Requirements Analysis[END_REF].

The most similar approach to ALISA in integrating architecture and requirements is by AutoFocus 3 [START_REF] Aravantinos | Autofocus 3: Tooling concepts for seamless, model-based development of embedded systems[END_REF] and Whalen et al. [START_REF] Whalen | Your "what" is my "how": Iteration and hierarchy in system design[END_REF]. Whalen et al. describe how SysML can be used with requirements models to accommodate the essential hierarchical nature of system engineering: a flow from more abstract (system requirements) to less (software requirements, then architecture models and code). It is key to recognize that there may be existing architectures and implementations that flow 'upward' to constrain requirements. This paper illustrated that it is often component interaction that provides most system failures, which can be traced to improper requirements decomposition and refinement. AutoFocus 3 [START_REF] Aravantinos | Autofocus 3: Tooling concepts for seamless, model-based development of embedded systems[END_REF], from the Fortiss Research Group, is a model-based engineering platform that, like ALISA, supports Eclipse-based end-to-end system development, starting with requirements and finishing with architecture. The two projects have a lot in common; key differences include the languages underpinning the architecture models (AADL in the case of ALISA, a custom language in for AutoFocus), and the verification mechanisms supported (nuSMV model checking in the case of AutoFocus; any AADL compatible verification approach in the ALISA case).

The concept of 'virtual integration' tries to leverage the promise of these model-centric approaches to reduce cost/cycle-time and risk (i.e., rework) by using early, and frequent, virtual integration, illustrated in the System Architecture Virtual Integration (SAVI) initiative ( [START_REF] Redman | Virtual integration for improved system design: The AVSI system architecture virtual integration (SAVI) program[END_REF], [START_REF] Feiler | System architecture virtual integration: An industrial case study[END_REF]). For simplicity, a related paper [START_REF] Rungta | Helping system engineers bridge the peaks[END_REF] suggests doing requirements modeling directly in the architecture-modeling tool (in this case, Simulink). Although adoption and ease-of-use goals are important, our experience suggests this is not ideal for complex requirements models and higher layers of abstraction. For architecture-centric approaches the specific details of the 'architecture' is ambiguous. There are at least four types of architecture we have identified:

• Functional architectures capture functional requirements but with little or no information about how those functions will be encapsulated in components. • Conceptual architectures specify how a system is decomposed into software and hardware components and the interfaces between them. Conceptual architectures are used during architecture trade studies and acquisition planning. • Design architectures specify detailed performance characteristics of individual components, including internal design detail to the level required to support the analyses desired.

• Implementation architectures specify details needed to integrate and verify an overall system; for example, data that can be used to automatically generate configuration files or perform model-based testing. This overlapping of abstractions makes it very difficult to properly separate solution context from problem context. Our intent is to provide separate languages (and vocabularies) for discussing these abstractions (for example, requirements specification tools for "functional architectures"), linked with shared identifiers.

In architecture-centric approaches, there is no explicit notation for capturing requirements (as part of a single process). For instance, the values for rate of change of speed thresholds are defined external to the modeling approach. This makes it unclear where and why these values are derived. For example, if the car we are building is a sports car, high acceleration may be desirable. If the car is a minivan (where small children may be more likely), high acceleration may be undesirable. To add traceability and rationale from requirements to architecture, we focus on linking stakeholder goals, system requirements, and an assurance case model for mapping verification strategies to goals. The compositional reasoning from [START_REF] Whalen | Your "what" is my "how": Iteration and hierarchy in system design[END_REF] could be integrated as another technique for modeling architecture components and verification strategies.

III. LANGUAGES

Defining and verifying requirements rely on several concepts, that are addressed today by separate tools that are not integrated. Each tool covers one or several concepts but does not address the whole process from requirement definition to system validation. As shown in Table I, we distinguish the following concepts, which we call the four pillars of system integration [START_REF] Feiler | Four pillars for improving the quality of safety-critical software-reliant systems[END_REF]:

• Requirements and Goal Definitions: defines the stakeholders, system objectives and requirements. Requirements engineering frameworks offer a formal specification of system requirements, avoiding textual specification. There are several tools to capture and model requirements, such as KAOS [START_REF] Dardenne | Goal-directed requirements acquisition[END_REF] or RDAL [START_REF] Blouin | Defining an annex language to the architecture analysis and design language for requirements engineering activities support[END_REF]. • Architecture Specification: capture the system architecture structure. This is currently managed by languages such as SysML [START_REF] Omg | Systems Modeling Language[END_REF] or AADL [START_REF]AS5506 -Architecture Analysis and Design Language[END_REF].

• Verification: analyze system artifacts (i.e. model, code, specification), to check requirements. However, these activities are not directly related to the system requirements specifications. This is currently handled by model analysis tools, such as Resolute [START_REF] Gacek | Resolute: an assurance case language for architecture models[END_REF]. • Claims, Arguments, Assurance: show how the system enforce the requirements and provides confidence about system quality. This is currently handled by linking verification to requirements and architecture using Structured Assurance Cases (SACM) [START_REF]Object Management Group. Structured assurance case metamodel (SACM)[END_REF]. One (or several) pillars are supported by existing tools, but, as the sparseness of Table I shows, the artifacts are independent and loosely coupled, and thus, do not cover the entire development process, from requirements specification to system validation. In addition, some tools support the same pillars but with a different (and potentially inconsistent) approach.

For that reason, we propose to unify these concepts. Leveraging existing approaches, we address each pillar with a separate language, and connect them with tool support. Using such an approach, users can then specify their requirements, attach them to the architecture and ultimately, validate them, demonstrating system compliance with the requirements.

We defined the following languages:

• ReqSpec: stakeholder goals and system requirements.

The language borrows concepts from RDAL [START_REF] Blouin | Defining an annex language to the architecture analysis and design language for requirements engineering activities support[END_REF] and KAOS [START_REF] Dardenne | Goal-directed requirements acquisition[END_REF]. • Verify: for verification activities, verification plans, methods (i.e. how to analyze and process system artifact to verify a property). This language is based on concepts from SVM [START_REF] Aldrich | Managing verification activities using SVM[END_REF], JUnit [START_REF] Massol | JUnit in action[END_REF] and Resolute [START_REF] Gacek | Resolute: an assurance case language for architecture models[END_REF]. • Alisa: for defining assurance work areas, tasks This language borrows concepts from Mylyn [START_REF] Kersten | Mylar: A degree-of-interest model for IDEs[END_REF]. • Assure: for assurance case instances. This language reuses concepts from JUnit [START_REF] Massol | JUnit in action[END_REF], Resolute [START_REF] Gacek | Resolute: an assurance case language for architecture models[END_REF], SACM [START_REF]Object Management Group. Structured assurance case metamodel (SACM)[END_REF] These languages have been implemented within Eclipse using the Xtext [START_REF] Bettini | Implementing Domain-Specific Languages with Xtext and Xtend[END_REF] framework. Our tool supports requirements/goals specification, validation methods and activities to check requirements enforcement in the architecture/implementation and automatic assurance case generation using the Goal Structuring Notation (GSN) 1 The tools check for requirements coverage (what architecture elements is missing a requirement, and vice versa), consistency (is there conflict between requirements) and auto-generate assurance cases using the GSN notation and tooling from [START_REF] Matsuno | An implementation of GSN community standard[END_REF] to show how requirements are validated and enforced within the architecture.

Note that we are not committed to a requirements → architecture mapping; indeed, in most cases we expect to have an existing architecture and requirements models, so the tracing can be either direction. We call this approach "architecture-led requirements specification" to capture the notion that the architectural model is the central hub of our model-driven engineering approach, with the spokes being the requirements, verification plans, and other artifacts. This does 1 http://www.goalstructuringnotation.info not demand that an architecture exist before requirements, but it does acknowledge that a strictly linear process is not realistic.

IV. THE LIGHTBULB EXAMPLE

We show how to use ALISA languages and concepts on a simple system: a light-bulb being powered by a battery. The objective is that the battery has enough capacity to power the bulb.

The architecture of this system is shown in Figure 2 (the AADL textual representation is shown in Listing 1). It consists of two devices: one battery and one bulb. Both components are connected through a power socket. The goal of our example is to show that the battery has enough capacity to power the bulb.

While the graphical representation does not include AADL properties (that specify power capacity and budgets), the textual representation (listing 1) includes such information to capture the power capacity and budget. To specify the system requirements, the first step is to specify the stakeholders of the system, as shown in listing 2. For this example, we will keep the number of stakeholders to one, the system electrician. The next step consists in defining the stakeholders requirements, also known as goals (i.e. what the system is supposed to be and what constraints it is supposed to comply with). Goals definition are written using the ReqSpec language, as illustrated in listing 3. A goal is bound to a component (in the present example, the global system), a description and is associated with a stakeholder (the electrician defined before). Once goals are defined, one should define the system requirements. The ReqSpec language is also used to define system requirements, as shown in listing 4. A system requirement is associated with a component, defines a description and is ultimately associated with a goal so that the tool is able to trace goals coverage (what goals are being linked to system requirements) but also architecture validation (what components have requirements). Then, verification plans are defined with the Verify language, that specifies how requirements are verified. The assurance plan is separated by claim being validated using analysis tools. Listing 5 shows that the system requirements previously defined are supported by a claim c1 that checks that the system has enough power. This claim is verified by a verification activity (mylibrary.electric_requirements, defined in a general verification library) that will analyze the AADL model and ultimately, check the property values, making sure that the power provided by the battery is more than the power required by the bulb. Ultimately, the overall assurance plan is defined using the Alisa language that defines verification plans are executed (ordering of tests). This is shown in Listing 6, which shows a definition of a basic assurance plan that executes the verification plan defined before (myplan). a l i s a myplan assurance plan power f o r s i m p l e a l i s a p o w e r : : i n t e g r a t i o n . i [ assert myplan ] Listing 6. Assurance Plan Workflow (ALISA lang.)

We have also added a function to automatically export the result of the verification process into an assurance case using the Goal Structuring Notation (GSN) [START_REF] Matsuno | An implementation of GSN community standard[END_REF]. The objective is to formalize the validation activities into a standardized notation. Our tool export these results into a GSN format that can be processed by the D-case assurance case tool [START_REF] Matsuno | A dependability case editor with pattern library[END_REF]. The GSN diagram of the bulb example is shown in Fig. 3. It details how the goal is decomposed and validated: the stakeholder goal (Power requirements are met) is decomposed into an evidence (The bulb has enough power) which are ultimately validated in the model (justification Analyze Power Across The System). Automating the production of the assurance case would avoid the labor costs associated with the production of such document, but also make them accurate with respect to the actual validation activities done on the model.

V. LARGER-SCALE EXAMPLE -THE SYSTEM ARCHITECTURE VIRTUAL INTEGRATION CASE

In 2009 the SAVI initiative published a white-paper [START_REF] Feiler | System architecture virtual integration: An industrial case study[END_REF] describing a case study outlining how the notion of virtual integration -the use of an annotated architecture model as the single source for architecture analysis -can dramatically reduce rework and verification costs in safety-critical systems development. We have begun to implement that example in the ALISA tool-chain in order to demonstrate ALISA's suitability to realistic problems. In the 2009 report we modeled the sample problem -a Tier 1 airplane system -in AADL, one of the components of the ALISA tool-chain. We have completed this analysis using the ReqSpec tools, reverse engineering the requirements both from the existing architectural documents and pre-existing natural language requirements.

Figure 4 shows the SAVI Tier 1 model components, and figure 5 shows a portion of the Tier 2 model of the Integrated Modular Avionics subsystem. Note that AADL has a robust behavioral specification language, shown in Figure 6.

From these architectural models we focused on the flight guidance subsystem, creating appropriate requirements and verification specifications for these systems. The Verify language asserts that a given claim in the requirements (ReqSpec) is met. Listing 8 shows the verification plan for the requirements defined in listing 7. The Plugins.ResourceAnalysis verification activity (listing 8) calls a separate, standalone verification tool to check the associated requirement and ultimately returns one of {True, False, Unknown}. The automatic traceability support in our tool propagates the truth-value of each claim to mark requirements as satisfied (claims are True) or unsatisfied (claims are Unknown or False). The result will then be saved and used later to build the associated GSN (as the one shown in figure 3 for the lightbulb example).

We are currently researching better support for more complex propagation of verification outputs. For example, we may use semantics that provide for another verification activity if the first attempt is either Unknown (e.g. a model checker times out) or False (which we are calling fail-then semantics).

VI. CONCLUSIONS AND FUTURE WORK

In this paper we presented ALISA, our vision for integrating four pillars for incrementally building systems: requirements specifications, architecture models, verification techniques, and assurance case traceability between the first three. We explained how we created DSL-based tooling to build these pillars, using a simple example. We then presented our example from an avionics domain to support our claim that the ALISA approach promises to reduce architecture design space exploration and verification overhead.

Our current and future work is to work with industry partners to add functional and safety requirements to an existing safety-critical system. We will apply the ALISA tools to perform compositional verification to provide assurance evidence. We are currently translating existing requirements from a DOORS and Excel environment to an ALISA-based requirements and safety hazards specification. We hope to demonstrate measurable improvement in requirements coverage and consistency. This will show the value of ALISA in early project phases. Our ultimate aim is to show measurable reduction in system rework costs by earlier defect detection. The certification process for safety-critical systems is one place where demonstrating compliance can produce large savings, so we are working with a collaborator to to produce additional evidence and certification artifacts to complement their testing evidence. Future work also includes integrating an assessment of requirements uncertainties (such as described by [START_REF] Nolan | Managing requirements uncertainty in engine control systems development[END_REF]), in order to further circumscribe the set of requirements that need to be checked. For example, in a car we may already be comfortable with our level of knowledge in the anti-lock braking subsystem, but less sure about the new fuel injector. We have also created import and export mechanisms with the OMG's Requirements Interchange Format (ReqIF) 2 in order to facilitate interchange.

Fig. 1 .

 1 Fig. 1. The Double-V model, showing sources of errors

Fig. 2 .:

 2 Fig. 2. AADL model of the bulb example

  organization mycompany stakeholder e l e c t r i c i a n [ f u l l name " John Doe " ] Listing 2. Stakeholders definition

  stakeholder goals mygoals f o r s i m p l e a l i s a p o w e r : : i n t e g r a t i o n [ goal g1 : " Power OK" [ d e s c ri p t i o n "We should be a b l e t o power t h e b u l b " r a t i o n a l e " W i t h o u t l i g h t , we cannot see " stakeholder mycompany . e l e c t r i c i a n ] ] Listing 3. Stakeholders Goals (REQSPEC lang.)

requirement s p e c i f i c a t i o n myrequirements f o r

  s i m p l e a l i s a p o w e r : : i n t e g r a t i o n [ requirement enough power : " The b a t t e r y should have \ enough power " [ compute a c t u a l b u d g e t d e s c ri p t i o n t h i s " should have a b a t t e r y w i t h enough \ power f o r t h e b u l b " see goal mygoals . g1 ] ] Listing 4. System Requirements (ReqSpec language)

  plan myplan f o r s i m p l e a l i s a p o w e r : : i n t e g r a t i o n . i [ claim c1 f o r myrequirements . enough power [ assert a l l [ m y l i b r a r y . e l e c t r i c r e q u i r e m e n t s ] argument " The b u l b has enough power " ] ] Listing 5. Validation Plan (VERIFY lang.)

Fig. 3 .

 3 Fig. 3. GSN export example

Fig. 4 .

 4 Fig. 4. Tier 1 (system view) of SAVI proof of concept

Fig. 5 .

 5 Fig. 5. Tier 2 AADL model of SAVI PoC

ACKNOWLEDGMENTS Copyright 2015

 2015 Fig. 6. Behavioral (flow) modeling in AADL