D1.2 Requirements Speci cation · D1.2- Requirements Speci cation Executive Summary This document...

D1.2Requirements Specification

Project number: 644080

Project acronym: SAFURE

Project title:SAFety and security by design for interconnected mixed-criticalcyber-physical systems

Project Start Date: 1st February, 2015

Duration: 36 months

Programme: H2020-ICT-2014-1

Deliverable Type: Report

Reference Number: ICT-644080-D1.2

Work Package: WP 1

Due Date: 21st November, 2016

Actual Submission Date: 21st November, 2016

Responsible Organisation: ESCR

Editor: Cheng Lu

Dissemination Level: PU

Revision: 1.0

Abstract:This SAFURE requirements specification provides a list of functionaland non-functional requirements corresponding to different use casesdefined in D1.1

Keywords:requirements, automotive, telecommunication, multi-core, functional,non-functional

This project has received funding from the European Union’s Horizon 2020research and innovation programme under grant agreement No 644080.

This work is supported (also) by the Swiss State Secretariat for Education, Research and Innovation (SERI)under contract number 15.0025. The opinions expressed and arguments employed herein do not necessarilyreflect the official views of the Swiss Government.

D1.2- Requirements Specification

Editor

Cheng Lu(ESCR)

Contributors

Christina Petschnigg, Martin Deutschmann (TEC)Stefania Botta, Luigi Santamato (MAG)Carolina Reyes (TTT)Mikalai Krasikau (SYSG)Jonas Diemer (SYM)Sylvain Girbal (TRT)Daniel Thiele, Robin Hofmann (TUBS)Jaume Abella (BSC)Marco Di Natale (SSSA)Philipp Miedl, Rehan Ahmed (ETHZ)Dominique Ragot (TCS)

DisclaimerThe information in this document is provided ”as is”, and no guarantee or warranty is given that theinformation is fit for any particular purpose. The users thereof use the information at their sole riskand liability.

SAFURE D1.2 Page I


Executive Summary

This document provides the requirements for the SAFURE project corresponding to different use caseswhich are defined in Task T1.1. The common requirements are listed in Chapter 2. The requirementsof the telecom scenario are described in Chapter 3. The requirements of the automotive multi-corescenario are described in Chapter 4. Finally, the requirements of the automotive network scenario aredescribed in Chapter 5.All the requirements are categorized into functional and non-functional requirements. The non-functional requirements include subclasses such as security, safety, time, temperature, mixed-critical,hardware platform, etc. In addition, the requirements, which have already been integrated into SA-FURE project at the time of this delivery, are listed separately at the beginning of each related chapter.The integrated requirements means that these requirements are already been fulfilled at the time ofthis delivery. As a result of Task T1.2, the D1.2 requirements specification will be used as referencein the other SAFURE work packages to implement and analyze platforms and demonstrators.

SAFURE D1.2 Page II


Contents

1 Introduction 11.1 Objectives of D1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Use of the D1.2 Outcomes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Methodology of definition of requirements . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Common Requirements for All Scenarios 32.1 Integrated Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Functional and Non-functional Requirements for Scenario 1: Telecom Scenario 103.1 Integrated Requirements for Telecom Scenario . . . . . . . . . . . . . . . . . . . . . . . 103.2 Functional Requirements for Telecom Scenario . . . . . . . . . . . . . . . . . . . . . . 123.3 Non-functional Requirements for Telecom Scenario . . . . . . . . . . . . . . . . . . . . 13

4 Functional and Non-functional Requirements for Scenario 2: Automotive Multi-Core Use Case 174.1 Integrated Requirements for Automotive Multi-Core Scenario . . . . . . . . . . . . . . 174.2 Functional Requirements for Automotive Multi-Core Scenario . . . . . . . . . . . . . . 184.3 Non-functional Requirements for Automotive Multi-Core Scenario . . . . . . . . . . . 18

5 Functional and Non-functional Requirements for Scenario 3: Automotive NetworkUse Case 205.1 Integrated Requirements for Automotive Network Scenario . . . . . . . . . . . . . . . 205.2 Functional Requirements for Automotive Network Scenario . . . . . . . . . . . . . . . 225.3 Non-functional Requirements for Automotive Network Scenario . . . . . . . . . . . . . 22

6 Summary 266.1 Summary of the Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.2 Use of the Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

SAFURE D1.2 Page III


List of Figures

1.1 Workplan for SAFURE Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

SAFURE D1.2 Page IV


List of Tables

2.1 Integrated Common Non-Functional Requirements for All Scenarios . . . . . . . . . . 52.2 Common Functional Requirements for All Scenarios . . . . . . . . . . . . . . . . . . . 62.3 Common Non-Functional Requirements for All Scenarios . . . . . . . . . . . . . . . . . 9

3.1 Integrated Functional Requirements for Telecom Scenario . . . . . . . . . . . . . . . . 103.2 Integrated Non-Functional Requirements for Telecom Scenario . . . . . . . . . . . . . 113.3 Functional Requirements for Telecom Scenario . . . . . . . . . . . . . . . . . . . . . . 123.4 Non-functional Requirements for Telecom Scenario . . . . . . . . . . . . . . . . . . . . 16

4.1 Integrated Functional Requirements for Automotive Multi-Core Scenario . . . . . . . . 174.2 Functional Requirements for Automotive Multi-Core Scenario . . . . . . . . . . . . . . 184.3 Non-functional Requirements for Automotive Multi-Core Scenario . . . . . . . . . . . 19

5.1 Integrated Functional Requirements for Automotive Network Scenario . . . . . . . . . 205.2 Integrated Non-functional Requirements for Automotive Network Scenario . . . . . . . 215.3 Functional Requirements for Automotive Network Scenario . . . . . . . . . . . . . . . 225.4 Non-functional Requirements for Automotive Network Scenario . . . . . . . . . . . . . 25

SAFURE D1.2 Page V


Chapter 1

Introduction

1.1 Objectives of D1.2

The main objective of deliverable D1.2 is to derive a list of requirements from the use cases of deliverableD1.1. All the requirements will be categorized and grouped in order to guide development in the otherSAFURE work packages.

1.2 Use of the D1.2 Outcomes

The requirements specified in deliverable D1.2 are an important basis for other deliveries and workpackages of the SAFURE project. These requirements have been specified by the project partnersbased on the use cases presented in D1.1. The work packages WP2, WP3, WP4, and WP5 aim atrefining these requirements as well as implementing and analysing platforms that realize the defineduse cases fulfilling the stated requirements. Finally, the implementations are going to be evaluatedagainst the use case definitions in work package WP6. The dependencies between the different workpackages are illustrated in Figure 1.1.

Figure 1.1: Workplan for SAFURE Project

SAFURE D1.2 Page 1 of 27


1.3 Methodology of definition of requirements

The document aims to provide a complete set of requirements for the SAFURE platform. To providea solid basis for extracting the requirements, several relevant use cases have been identified and speci-fied in D1.1. Each partner has been requested to identify functional and non-functional requirementsdepending on the use cases. To this end, each partner has been provided an input sheet to providethese requirements. Following the requirement collection phase the consolidation phase started. Thegoal of the consolidation phase is to eliminate repeated requirements, assure similar wording, andidentify possible conflicts between the requirements. The outcome of the consolidation phase is onelist of functional and non functional requirements which can be found in this document. The linkbetween the consolidated requirements and the initial requirements of the partners has been kept toenable backtracking in case of unclear issues. Furthermore, assessment is also introduced for each re-quirement and will be filled in by each partner in order to track the status of the requirements duringthe project. To distinguish those requirements, which have been already fulfilled or integrated intoSAFURE project at the time of this delivery, a list of integrated requirements will be stated separatelyat the beginning of each corresponding chapter.

There are two different types of tables for listing the functional and non-functional requirements.Both types of tables include column ”ID”, which is used for tracking the each requirement, column”Description”, which states the details of the requirement, and column ”Comments”, which gives shortremarks for the requirement. The non-functional requirements table has an additional column ”Type”for distinguishing different types of the non-functional requirements.



Chapter 2

Common Requirements for AllScenarios

This chapter presents the functional and non-functional requirements in a general view which shouldbe applied into all three use cases. The non-functional requirements are further divided into real-time operating system, timing, temperature, security, safety, mixed criticality and hardware platformrequirements. The common requirements which have been already integrated into SAFURE at thetime of this delivery, have been extracted and listed in Section 2.1.

2.1 Integrated Requirements

The table 2.1 lists the common requirements which have been already integrated into SAFURE projectat the time of this delivery.

Type ID Description of Requirements Comments

Real-TimeOperatingSystem

CR-NF-001 The hypervisor shall provide real-time guarantees when schedulingvirtual machines/partitions

CR-NF-003 The real-time operating systemshould provide ways to access thehardware monitoring features of thehardware platform. Virtualizationneeds to have a minimal impact onthe availability and accuracy of themonitoring features.

For monitoring features requiredby WP3 and WP4

Timeanalyses

CR-NF-032 An upper bound must be computedon the delay of communication overEthernet for safety-critical traffic.

Applies to all use cases for whichtiming analysis shall be per-formed.

CR-NF-033 An upper bound must be com-puted on the delay of communica-tion over Ethernet for safety-criticaltraffic also in the presence of un-known/unexpected traffic.


CR-NF-034 An upper bound must be com-puted on the hardware utiliza-tion of communication over Ether-net (bandwidth, buffer) for safety-critical traffic.




Temperature CR-NF-013 The hypervisor should provide sup-port to treat energy/temperatureinformation on scheduling level orpropagate it to the dedicated userapplications.

In hardware-virtualization mode,Peripheral Management AccessUnit (PMAU) and scheduling/synchronization API can beused by application

SecurityCR-NF-014 The hypervisor shall provide means

to confine HW-based covert/sidechannels.

In hardware-virtualization mode,PMAU and scheduling /synchro-nization API can be used by ap-plication as appropriate setup oftime and partition isolation

CR-NF-017 The hpervisor should provide sup-port for Public Key Infrastructure(PKI).

e.g. file provider API

CR-NF-020 The cryptographic services shallprovide a common interface toHardware Security Models and Soft-ware libraries.

Interfaces are provided so thatother software applications donot need to know the implemen-tation of all cryptographic ser-vices

Mixed-Critical

CR-NF-023 The hypervisor shall provide tempo-ral and spacial separation of appli-cations.

Generic from the DoA. Inte-grated for Safety.

CR-NF-025 Multiple safety/security criticalitylevels have to be considered forsoftware/hardware components, notonly a ’naive’ separation betweenthe critical and the non-critical ones(best-effort). These different levelsof criticality have to be taken intoaccount at tool, especially at theanalysis level of the tool composingthe tool-flow

Hardwareplatform

CR-NF-029 The proposed hardware platformsto be evaluated in WP4 for fi-nal selection should encompass someshared hardware resources sharedby several cores (>4) such as sharedmemory (such as distributed memo-ries or caches, preferably distributedSRAM memories), but also the SoCinterconnect, and I/O devices. Thereal-time analysis should not onlytake the shared memory into ac-count, but also the other resources.

WP4 requirements. Covered bythe chosen hardware platform.

CR-NF-030 According to the system predictabil-ity criteria defined by the PREDA-TOR project, there is a strong needfor large local memories on themulti-core platform.The size of thelocal memories should be enough forthe storage (instructions & data) ofany single application task.

To control interferences. Coveredby the chosen hardware platform.



CR-NF-031 The selected hardware platformshould encompass multi-core tech-nology with at least 4/8 cores suchas the 4-core iMx6q, the 8-coreP4080 or the 12-core T4240. Tomake sure that all the techniquesproposed in the SAFURE projectare scalable, dual-core architecturesshould be avoided as they usu-ally encompass specific non-scalablehardware features.

From the DoA, targeting multi-cores. Covered by the chosenhardware platform.

Table 2.1: Integrated Common Non-Functional Require-ments for All Scenarios



2.2 Functional Requirements

ID Description of Requirements Comments

CR-F-001 Mixed-critical safety requirements and time-critical requirements need to be coupled in atleast one of the use-case supporting PikeOS, in-cluding the possibility to run concurrently dif-ferent tasks with different safety levels, or theability to support a degraded mode for lowestcritical tasks.

Requirement for the research per-formed in WP4. Else WP4 will usea dedicated prototype. Integratedin the WP4 prototype.

CR-F-002 The use-cases should quantify their usage andrequirements in term of accesses to the differ-ent shared hardware resources of the target plat-forms for the adaptive solution to guarantee theassociated requirements based on observed be-havior.

Requirements for QoS algorithm de-veloped in WP3.

Table 2.2: Common Functional Requirements for All Scenarios

2.3 Non-Functional Requirements



CR-NF-002 All the use cases should use toolsand SW that are an expression ofan acknowledged standard or have areliable open source implementation

Timeanalyses

CR-NF-005 System description (topology, etc.)must be available in an accessibleformat.


CR-NF-006 System configuration (communica-tion, tasks, etc.) and timing prop-erties (execution times, frame sizes,etc.) must be available in an acces-sible format.


CR-NF-007 System constraints (deadlines, max.load, etc.) should be available in anaccessible format


CR-NF-008 Timing behavior must beknown/specified for all arbitrationpoints (CPU scheduler, networkarbitration, shared resource access,etc.)


CR-NF-009 For unknown time consumers (at-tackers), constraints should be spec-ified (e.g. what resources are af-fected).


CR-NF-010 Standard arbitration protocolsshould be used for OS and net-works (e.g. AUTOSAR, OSEK,Ethernet).

There will likely be no supportfrom SYM for non-standard /custom protocols for timing anal-ysis.



CR-NF-011 Timing properties should be derivedvia tracing, static analysis or bud-geting.


CR-NF-012 WCET analysis techniques and ded-icated isolation techniques shouldprovide Time Composability in tar-get multi-core systems by providingfeatures allowing us to compute orbound the co-running interferenceoverhead.

Security

CR-NF-015 The hypervisor shall support secureboot of the whole system and eachpartition separately.

CR-NF-016 The hypervisor shall provide secureupdate of a partition.

CR-NF-018 The SAFURE platform must pro-vide services for cryptographicmechanisms and handle cryp-tographic objects (i.e. keys,certificates). The services mustinclude the following features:a) Managing cryptographic keys.(Generating, deleting and storingkeys)b) Calculation of cryptographicfunctions:- Signature generation and verifica-tion- Message Authentication Codes(MACs)- Encryption and decryptionc) Management of cryptographiccertificates. (Storing and updatingcertificates)

This requirement needs to be ful-filled if a system wants to pro-vide security like confidentiality,integrity, and authenticity.



CR-NF-019 The cryptographic services mustprovide a configuration mechanismto define the access methods andrights to the cryptographic objects.a) The configuration shall only bedone by authorized entities.b) The access rights shall be en-forced by the security architecture.c) Access rights must be definablefor- Roles and Users- Services- Domainsd) Access rights shall define:- Overall access- Access to individual functions us-ing the cryptographic objects.(i.e.generating or deleting keys)e) Usage rights of cryptographic ob-jects should be defined:- Keys for encrypting, decrypting,signing, verifying.- If keys can be deleted, exported,derived or not.

This requirement needs be ful-filled if a system wants to provideaccess control.

SafetyCR-NF-021 A software component should not

be allowed to alter, contaminateor delay another software compo-nent’s code, I/O, scheduling, ordata storage areas in uncontrollableways, especially from the less crit-ical components to the most criti-cal ones. Time isolation and Spa-tial isolation have to be ensured.New isolation mechanisms can beintroduced to ensure software inde-pendence in multi-core systems, en-abling the safe execution of softwarecomponents with different criticalitylevels.

Generic from safety definition

CR-NF-022 Failure on hardware unique toa software component should notcause adverse effects on any othersoftware component.

Generic from safety definition

Mixed-Critical

CR-NF-024 Mixed-criticality must be supportedin hardware.

Mixed-criticality should be suffi-ciently isolated.



CR-NF-026 Incremental changes should be sup-ported in the design and verifica-tion. The tools should exploit theisolation to keep the effects of in-cremental changes as small as pos-sible for the higher levels of critical-ity. This feature is required for in-cremental certification.

Generic from mixed-critical defi-nition

Hardwareplatform

CR-NF-027 The hypervisor shall support theplatform selected in the telecom use-case.

CR-NF-028 The selected hardware platform hasto provide monitoring features suchas Performance Monitoring Counter(PMC) or hardware counters, allow-ing to monitor the timing behavior,the runtime workload on the differ-ent hardware resources, and powerconsumption or energy related fea-tures.

For monitoring features requiredby WP3 and WP4

Table 2.3: Common Non-Functional Requirements for AllScenarios



Chapter 3

Functional and Non-functionalRequirements for Scenario 1: TelecomScenario

This chapter presents the functional and non-functional requirements for the telecom use case. Thenon-functional requirements are further divided into real-time operating system, timing, temperature,security, mixed criticality and hardware platform requirements. The requirements which have beenalready integrated into SAFURE at the time of this delivery, have been extracted and listed in Section3.1.

3.1 Integrated Requirements for Telecom Scenario

The table 3.1 lists the functional requirements which have been already integrated into SAFUREproject at the time of this delivery.


S1-F-001 Linux/GNU based OS for the COTS. Needed for integration of thermalprotection mechanisms

S1-F-010 The hypervisor shall be able to execute Linuxand other runtime environments

Table 3.1: Integrated Functional Requirements for Telecom Scenario



The table 3.2 lists the non-functional requirements which have been already integrated into SAFUREproject at the time of this delivery.


Timeanalyses

S1-NF-003 One of the HW platforms must in-clude a COTS multi-core with atleast 4 cores (e.g. Freescale iMX6q,Freescale P4080)

This requirement should be com-patible with TRT ones on thiscase study The HW platformchosen provides this feature, sothis requirement is covered

S1-NF-004 The COTS multi-core in the previ-ous requirement must include someon-chip shared resources acrosscores: at least (1) a shared intercon-nection network between the coresand a shared cache or shared mem-ory, and (2) a shared memory con-troller. It is also valuable if suchmulti-core includes a cache memoryshared across cores.

This requirement should be com-patible with TRT ones on thiscase study The HW platformchosen provides this feature, sothis requirement is covered

Security S1-NF-010 The device shall protect communi-cations with the IMDs (ImplantableMedical Devices) and with the med-ical cloud server in accordance withthe SFPP security requirements.

Communication with IMD de-vices : to ensure a compatibil-ity with existing devices, secu-rity mechanism implemented inthe Bluetooth protocol are used.

Hardwareplatform

S1-NF-019 The hardware platform shall offermultiple cores.

All platforms selected by SA-FURE are multicore.

S1-NF-021 The hardware platform shall offeran USB interface.

All platforms selected by SA-FURE have an USB interface

S1-NF-030 Multi Core Processor (MPSoC) Fundamental use-case require-ment. Covered by the chosenhardware platform

S1-NF-031 One Temperature Sensor per Core Required for integrating thermalprotection mechanisms. Coveredby the chosen hardware platform

S1-NF-032 The resolution of the TemperatureSensors needs to be equal/smallerthan 1 K

Required for integrating thermalprotection mechanisms. Coveredby the chosen hardware platform

S1-NF-033 The system has to have power orthermal management build in.

Required for providing thermalprotection Covered by the chosenhardware platform

Table 3.2: Integrated Non-Functional Requirements for Tele-com Scenario



3.2 Functional Requirements for Telecom Scenario


S1-F-002 The functional architecture of the telecommuni-cations use case(s) should be defined (at least inpart) by means of a formal (possibly standardand commercial) modeling language.

S1-F-003 The device shall provide applications to controland monitor the IMD. These applications shallbe configurable by authenticated user only.

An application will be developed tomonitor/control a medical device ora simulated device. It will dependon the availability of a device usingopen communication protocols andproviding an API/SDK to access thesensor streams.

S1-F-004 The device shall be able to forward datarecorded or processed in the critical environ-ment to a cloud server. This requirement impliesthe existence of inter-partition communicationmeans.

An application will be developed totransmit the data from the criticalpartition to a cloud server.

S1-F-005 The device shall allow the update of medical ap-plications over the air. For example the updatecould be stored on a cloud server.

An android market(not the GooglePlay market) will be used to storethe application. An OSS such asFdroid could be used to create ourown repository containing the appli-cation.

S1-F-006 The device shall provide the Android operatingsystem with all basic applications (browser, mailclient, multimedia player, phone client etc).

It will depend on the features of-fered by the hypervisor and specifi-cally the screen sharing between twoAndroid partitions. In this case,the non-critical partition will con-tain basic applications.

S1-F-007 The device shall provide a mechanism to sepa-rate the domain specific applications (e.g. IMDapplications) from the general purpose applica-tions or prohibit the installation of those generalpurpose applications by users.

The separation between the IMDapplications is made by design. Infact, PikeOS is used to separate thecritical applications (IMD apps) andgeneral purpose applications.

S1-F-008 A mechanism shall enforce authenticity and in-tegrity of the software stack in accordance withthe SFPP security requirements.

S1-F-009 Remote control of the platform shall be availableto legitimate users in accordance with the SFPPsecurity requirements.

Control orders of IMD devices aretransmitted from the medical serverover the specific VPN used to trans-mit medical data. After that, thesedata are sent to the IMD having ac-tuators.

Table 3.3: Functional Requirements for Telecom Scenario



3.3 Non-functional Requirements for Telecom Scenario



S1-NF-001 The critical environment contain-ing medical applications shall imple-ment a real-time operating systemenforcing the security policy regard-ing real-time communication needs.

An Android partition is used asa critical environment. Securitypolicy is ensured by design by us-ing an hypervisor(separation ker-nel) and by using Android per-missions.

S1-NF-002 The operating systems running onthe PikeOS hypervisor should bekept as minimalistic as possible, al-lowing direct access of the hard-ware close to bare bone style. Com-plex unpredictable scheduler poli-tics such as the one included inLinux systems should be avoidedfor safety critical systems, espe-cially those with time-critical re-quirements.

Requirements for controlling in-terferences on time critical sys-tems.

Timeanalyses

S1-NF-005 Performance monitoring counters(PMCs) must be abundant and al-low tracking activities occurring inthe on-chip shared resources suchas the number (and preferably alsothe type) of accesses to the on-chip interconnection network andthe memory controller indicated inthe previous requirement.

This requirement should be com-patible with TRT ones on thiscase study.

Temperature

S1-NF-006 The device temperature shall re-main under 45◦. In particular, thisshall be the case when the An-droid environment is being inten-sively used.

S1-NF-007 Different application modes of thedevices should be required for low,medium and high computational ef-fort

To enable sophisticated thermalprotection mechanisms

S1-NF-008 Different applications should havedifferent thermal characteristics foreach core

To enable sophisticated thermalprotection mechanisms

S1-NF-009 The applications have to be peri-odic.

Required for providing thermalprotection

Security

S1-NF-011 The device shall protect in confiden-tiality and authenticity critical datain accordance with the SFPP secu-rity requirements. In particular ap-plication data shall be protected inconfidentiality, integrity, authentic-ity and availability.

These properties are ensured byusing security mechanisms pro-vided by Android(Cipher class)or CycurLIB with PikeOS.



S1-NF-012 Access to the device, and especiallyaccess to the critical environmentshall be granted only after a correctauthentication of the user in accor-dance with the SFPP security re-quirements.

Android authentication mech-anism(local or authenticatingserver) will be used

S1-NF-013 The device shall implement a sepa-ration kernel with at least one par-tition for non-critical applicationsand one partition for critical ap-plications in accordance with theSFPP security requirements.

An hypervisor compatible withthe hardware platform is to sep-arate the 2 environments: En-sured by Design(Hypervisor andarchitecture supporting the de-vice)

S1-NF-014 The telecommunications use caseshould provide one example of com-munication or interaction with secu-rity concerns/issues that can be ex-pressed in a quantitative and formalway.

S1-NF-036 The device shall protect theanonymity and the confidentialityof the medical data transmitted tothe medical staff

A specific VPN will be used totransmit only the medical databetween the terminal device to amedical server.

S1-NF-037 The device shall protect the pri-vacy, the anonymity and the con-fidentiality of the data trans-mitted to the support productstaff(manufacturer, seller of theproduct, etc.)

A specific VPN will be used totransmit only the data concern-ing IMD devices. The VPN willbe used between the terminal de-vice and a server used by the sup-port product staff. These datawill be used by the support teamto ensure the correct functioningof the IMD devices.

S1-NF-038 Anonymity: A subset of the medicaldata shall be provided to authorizedusers, without any information thatmay reveal the identity of the IMDholder

S1-NF-039 Privacy: The device shall be ableto ensure that a subset of the datais accessible only to the terminalholder and to other users to whomthe terminal holder has granted ac-cess

Mixed-Critical

S1-NF-015 Critical applications (e.g. medicalapplications) and non-Criticalapplications (mail/social net-work/game/...) should run at thesame time on the same system.

Fundamental use case require-ment



Hardwareplatform

S1-NF-016 The hardware platform shall beable to run Android above PikeOS.Preferably the latest version of An-droid : Android 5.0 a.k.a Lollipop

This will be ensured by using thework made by SYSGO. The An-droid OS will be used as a par-tition in PikeOS. The Androidpersonality will be provided by apartner

S1-NF-017 The hardware platform shall be ableto run the separation kernel PikeOS.

The platform selected by TCS forthe telecommunication use casewill be supported by PikeOS.SYSGO will provide an instal-lation with a PS Provided by apartner

S1-NF-018 The hardware platform shall be ableto run Linux OS above PikeOS.

SYSGO will provide a Linux run-ning PikeOS for the telecommu-nication platform

S1-NF-020 The hardware platform shall offer aGraphics Processor Unit (GPU) ad-dressed by at least one partition.

Either PikeOS provide a di-rect access to the GPU ofthe platform or provides a spe-cific driver to have an accessfrom multiple partitions to theGPU(indirectly).

S1-NF-022 The hardware platform may offeran Secure Digital High Capacity(SDHC) interface.

S1-NF-023 The hardware shall offer a 3G/4Ginterface.

All smart phones and sometablets have a 3G/4G interface

S1-NF-024 The hardware shall offer a Wi-Fiinterface in order to communicatewith the cloud server.

The chosen platform provides aWIFI interface

S1-NF-025 Documentation about the hardwareplatform shall be available and de-tailed enough to design a BinarySpace Partitioning (BSP).

S1-NF-026 The hardware platform shall allowto configure the boot loader.

Some manufacturers such asSONY allow us to configure theboot loader

S1-NF-027 The hardware platform shall bepreferably a smart phone, a tablet,or a development tablet (in this or-der).

S1-NF-028 The underlying hardware shall pro-vide an hardware virtualizationmechanisms set.

S1-NF-029 The underlying hardware may pro-vide an NFC interface.

S1-NF-034 Minimum one power sensor for theMPSoC.

This requirement would enablethe study of power covert chan-nels.



Other S1-NF-035 The number of applications has tobe limited

Required for providing thermalprotection

Table 3.4: Non-functional Requirements for Telecom Scenario



Chapter 4

Functional and Non-functionalRequirements for Scenario 2:Automotive Multi-Core Use Case

This chapter presents the functional and non-functional requirements for the automotive multi-core usecase. The non-functional requirements are further divided into architectural design, safety, security,timing, mixed criticality and hardware platform requirements. The requirements which have beenalready integrated into SAFURE at the time of this delivery, have been extracted and listed in Section4.1.

4.1 Integrated Requirements for Automotive Multi-Core Scenario



S2-F-002 A mechanism provided by OS shall enforce au-thenticity and integrity of the software stack inorder to satisfy safety goals.

ERIKA OS provides these mecha-nisms that are crucial for ISO26262compliance

Table 4.1: Integrated Functional Requirements for Automotive Multi-Core Scenario



4.2 Functional Requirements for Automotive Multi-Core Scenario


S2-F-001 The functional architecture of the automotiveuse cases should be defined (at least in part) bymeans of a formal (possibly standard and com-mercial) modeling language

S2-F-003 The Electronic Control Unit (ECU) must beable to manage a four cylinders engine and simu-late the control of automatic transmission gear-box.

Table 4.2: Functional Requirements for Automotive Multi-Core Scenario

4.3 Non-functional Requirements for Automotive Multi-Core Sce-nario


ArchitecturalDesign

S2-NF-001 Modeling all the components shouldbe required to simulate the entiresystem and allow a predictable timeanalysis and task/runnable alloca-tion.

Architectural Design Require-ment. The simulation is manda-tory for ISO26262. The timeanalysis is a new requirement.

Safety S2-NF-002 The automotive use case shouldprovide at least one example ofcommunication or interaction withsafety concerns/issues that can beexpressed in a quantitative and for-mal way.

Security

S2-NF-003 Controller Area Network (CAN) buscommunication should be protectedfrom external attacks.

S2-NF-004 The Data stored on multi-core ECUmust be protected against adver-saries.

S2-NF-005 The automotive use case should pro-vide at least one example of com-munication or interaction with secu-rity concerns/issues that can be ex-pressed in a quantitative and formalway.

S2-NF-006 There should be a mechanism toprevent/limit unknown/unexpectedtask activations (e.g. Interrupt Re-quest (IRQ) limiting)

S2-NF-007 A security mechanism for authenti-cation during flashing phase must beprovided.

Currently There is not a dedi-cated UC for this requirement,but it is important for securityaspects.



S2-NF-008 Internal memory access from not au-thorized devices must be blockedand refused.

S2-NF-009 All types of memory access from dif-ferent cores must be arbitrated toprovide freedom of interference.

Timeanalyses

S2-NF-010 Security SW Components shouldnot exceed 10% CPU load globally.

S2-NF-011 Total system should not exceed 80%CPU load for each core.

this requirement is mandatory toguarantee the correct schedulingto avoid the loss of task activa-tion.

S2-NF-012 The automotive use case should pro-vide at least one example of timingconstraints that need verification.

S2-NF-013 Temporal overheads for accessingshared resources must be known(cache, on-chip memory, IO, etc.)

Mixed-Critical

S2-NF-014 A mechanism for spatial and tempo-ral isolation of the two cores must beguaranteed in order to protect fromexternal attacks and meet safetygoals.

S2-NF-015 Engine Control Unit must be allo-cated on core 0, and a simulation ofautomatic transmission ECU mustbe allocated on core 1.

Hardware platformS2-NF-016 The automatic transmission ECUoutput commands must be simu-lated on CAN message and showedon external terminal.

Table 4.3: Non-functional Requirements for AutomotiveMulti-Core Scenario



Chapter 5

Functional and Non-functionalRequirements for Scenario 3:Automotive Network Use Case

This chapter presents the functional and non-functional requirements for the automotive network usecase. The non-functional requirements are further divided into security, timing, mixed criticality andsafety requirements. The requirements which have been already integrated into SAFURE at the timeof this delivery, have been extracted and listed in Section 5.1.In WP6, the implementation and evaluation of the automotive network use case is split into twodemonstrators: (a) a virtual prototype by TUBS, which will be mainly used to show the researchresults regarding advanced Ethernet features for safe mixed-critical communication (cf. Task T5.1),and (b) an actual Ethernet demonstrator by TTT showing the security features and anti-counterfeitingmeasures from Tasks T5.2 and T5.3. This separation is because, in the proposal phase, the involvedpartners have anticipated that the purpose of some of the advanced research topics in Task T5.1 ismainly to serve as guidelines for Ethernet setups and (potentially) future Ethernet standards. Theseadvanced ideas, most likely cannot be implemented in actual hardware during this project. However,partners TUBS and TTT will try to evaluate as much of the results from Task T5.1 on the actualdemonstrator as possible.

5.1 Integrated Requirements for Automotive Network Scenario



S3-F-001 The Software Defined Networking (SDN) mech-anism used to configure the (virtual) networkmust have access to all relevant switch configu-ration options, which will be identified in WP5.

Table 5.1: Integrated Functional Requirements for Automotive Network Scenario



The table 5.2 lists the non-functional requirements which have been already integrated into SAFUREproject at the time of this delivery.


Timeanalyses

S3-NF-014 Admission control must complete inbounded time.

Mixed-Critical

S3-NF-019 The switches and/or end pointsshall use Time and Space Partition-ing to separate traffic streams.

Covered by SOTA - Thereare switches and End Sys-tems already supporting TSN.Also, TTEthernet technologyused within SAFURE (physi-cal network demonstrator) coversthe time and space partitioningrequirement.

Table 5.2: Integrated Non-functional Requirements for Au-tomotive Network Scenario



5.2 Functional Requirements for Automotive Network Scenario


S3-F-002 The protocol for securely updating softwaremakes use of the PUF feature to secure a hard-ware fingerprint

PUF topic was discussed with theconsortium and it was concludedthat the PUF technology is in a tooearly stage for standardised applica-tion in the SAFURE relevant UCs.Further, the selected platform doesnot provide a PUF

Table 5.3: Functional Requirements for Automotive Network Scenario

5.3 Non-functional Requirements for Automotive Network Scenario


Security

S3-NF-001 The cryptographic services, such asthe management of cryptographickeys and certificates, shall be ap-plied to meet the needs of securecommunication in Ethernet-basedreal-time networks.

It is required for secure commu-nication for ethernet-based real-time network.

S3-NF-002 The network admission controllermust have an authorization mech-anism which allows only the autho-rized entities to send requests.

Authenticity is required.

S3-NF-003 There should be a mechanism toprevent/limit unknown/unexpectedtraffic (e.g. admission control, shap-ing)

S3-NF-004 The support for trust anchors andsecure storage of keys should be pro-vided for secure authentication andcommunication

Generic from security definition

S3-NF-005 Information collected within a vehi-cle should be authentic with respectto origin and time if the vehicle per-forms actions based on that infor-mation.


S3-NF-006 The mechanism is required to en-sure integrity for information col-lected within a vehicle. Especiallythe pieces of information the vehicleperforms actions on.


S3-NF-007 The mechanism is required to ensureavailability of ECUs for safety crit-ical applications (robustness to de-nial of service attacks).




S3-NF-008 Implementation of security algo-rithms must not violate timing con-straints.


S3-NF-009 Communication in Ethernet-basedreal-time network shall be securedwith regards to confidentiality, au-thenticity and integrity whilst re-specting real-time constraints (i.e.predictable latency and low jitter).

This requirement is required ifSAFURE aims to support securereal-time system applications.

S3-NF-010 For the initial demonstrator, a sim-ple level of verification and valida-tion of the security measures shouldbe ensured.

This is an implementation re-quirement. The verification andvalidation of the security mea-sures will be provided by the SA-FURE platform in the sense ofa man-in-the-middle attack, tim-ing analysis and worst case per-formance analysis.

S3-NF-011 Network-related security applica-tions should allow for global net-work flow control, increase networkdynamics and permit on-the-fly re-configuration for all types of trafficclasses.

In SAFURE, the inclusion of thenewly developed security mecha-nisms should not have a negativeimpact on the network behavior.

Timeanalyses

S3-NF-012 Time and safety critical traffic muststate their special requirements (e.g.deadlines, redundancy, weakly hardconstraints for typical case analysis)in a way which can serve as in inputdescription to our analysis tools.

S3-NF-013 If a traffic stream uses TypicalCase Analysis (TCA), its descrip-tion must provide enough informa-tion for a TCA analysis. TCA gives“m-out-of-k” guarantees (e.g. m outof k frames will meet their dead-line). Hence, the parameters m andk must be provided along with adeadline.

S3-NF-015 Network re-configuration must beperformed in a bounded time.

S3-NF-016 Each traffic stream must spec-ify whether it requires specialfault/failure tolerance, e.g. Au-tomatic Repeat Request (ARQ),TCA, redundant paths.

S3-NF-017 If a traffic stream uses ARQ, itsdescription must provide enoughinformation for the selected ARQscheme, i.e. the ARQ scheme,the retransmission timeout, and thenumber of expected retransmissions(e.g. errors).



S3-NF-018 Redundant paths must be specifiedat design time.

Mixed-Critical

S3-NF-020 Each traffic stream must be catego-rized into critical (e.g. time- and/orsafety-critical) or non-critical traffic(e.g. best effort).

S3-NF-021 The arbitration scheme in theswitches must support mechanismsto distinguish critical (e.g. tim-ing, safety) from non-critical trafficstreams to guarantee freedom frominterference/sufficient independencefor critical traffic streams.

Safety

S3-NF-022 There must be some kind of admis-sion control in the (virtual) networkto ensure robustness to denial of ser-vice attacks.

S3-NF-023 Switches and/or end stations (in thevirtual network) must support thedetection of hardware failures, e.g.broken links or switches.

S3-NF-024 Switches and/or end stations (in thevirtual network) must support mon-itoring schemes capable of timelydetecting attacks and misbehavingtraffic. The monitoring schememust be configurable, e.g. via SDN,and their parameters should be pro-vided, e.g. number of replenish-ment tokens and replenishment in-terval for leaky bucket shapers orl-repetitive arrival functions for ad-vanced monitoring.

S3-NF-025 Switches and/or end stations (inthe virtual network) must supportmechanisms to shape/block attack-ing/misbehaving traffic in a timelyand appropriate way. These mecha-nisms must be configurable, e.g. viaSDN.

HardwarePlatform

S3-NF-026 The SDN mechanisms together withthe (virtual) network equipment(e.g. switches) must support the re-configuration of the network.



S3-NF-027 SAFURE platform should provideNon-Volatile Memory (NVM) anda Physical Unclonable Function(PUF) feature.

PUF topic was discussed withthe consortium and it was con-cluded that the PUF technologyis in a too early stage for stan-dardized application in the SA-FURE relevant UCs. Further,the selected platform does notprovide a PUF

Table 5.4: Non-functional Requirements for Automotive Net-work Scenario



Chapter 6

Summary

6.1 Summary of the Requirements

The requirements described are corresponding to three different use cases. In particular:

• The Telecom Scenario, cf. Chapter 3, focuses on the requirements to provide secure com-munication between general-purpose smartphones and medical devices. In addition, timing,temperature, mixed-critical requirements are also considered to make smartphones and medicaldevices separate the processing of business operation from other processes in order to guaranteea high assurance safety for health applications.

• The Automotive Multi-Core Scenario, cf. Chapter 4, focuses on the requirements to providesecure and safety multi-core automotive use case. In particular, their aim is to guarantee memoryprotection between different cores and prevent malicious attacks through CAN protocol. Inaddition, timing, mixed-critical, architectural and hardware requirements are also considered todevelop Automotive Multi-Core scenario.

• The Automotive Network Scenario, cf. Chapter 5, focuses on the requirement specificationfor safe and secure mixed-critical communication. The requirements cover multiple aspectssuch as predictable timing, network reconfiguration and isolation, and secure communicationregarding confidentiality, authenticity, and integrity.

6.2 Use of the Requirements

All the requirements are derived to ensure safety and security in the design of cyber-physical sys-tems. For several embedded stakeholders, like: assurance market, medical sector, automotive OEMs,telecommunication market, and end users, these requirements should be taken into account and eval-uated. The project SAFURE will implemented the demonstrators which realize all the describedrequirements to provide safety and security for the mixed-critical cyber-physical systems.


D1.2 Requirements Speci cation · D1.2- Requirements Speci cation Executive Summary This document...

Documents

Transcript of D1.2 Requirements Speci cation · D1.2- Requirements Speci cation Executive Summary This document...