CHOSeN_D1_2a_Aeronautic Requirements analysis document (PU)

Cooperative Hybrid Objects Sensor Networks

Contract Number : INFSO-ICT-224327

DELIVERABLE NO

CHOSeN

Project Report

D1.2a

DELIVERABLE TITLE Requirements analysis document for aeronautic applications

AUTHOR Jirka Klaue (EADS)

DISCLOSURE LEVEL Public

VERSION V1.1

Copyright



CHOSEN Consortium

2008-2011

CHOSeN Public

Deliverable: D1.2a Requirements analysis document for aeronautic applications V1.1

Referenced Documents

[CHOSeN DoW]

CHOSeN Annex I - “Description of Work”

[DO160F]

Radio Technical Commission for Aeronautics (RTCA) DO-160F,

Environmental Conditions and Test Procedures for Airborne Equipment

[DO178B]

Radio Technical Commission for Aeronautics (RTCA) DO-178B,

Software Considerations in Airborne Systems and Equipment

Certification

[ABD0100]

Airbus Directives (ABD) and Procedures, ABD0100, Equipment-Design,

General Requirements For Suppliers

Copyright



CHOSEN Consortium 2008-2011

Page 2

CHOSeN Public


Abbreviation List

AFDX Avionics Full Duplex Ethernet

CFRP

CIDS

Carbon Fiber Reinforced Polymer

Cabin Intercommunication Data System

CRP

CW

LRI

LRU

MAC

MRO

MTTF

NDT

OEM

PAX

PHY

SHM

WSN

Carbon Fiber Reinforced Plastic

Crack-Wire

Line Replaceable Item

Line Replaceable Unit

Media Access Control

Maintenance, Repair and Overhaul

Mean Time to Failure

Non Destructive Testing

Original Equipment Manufacturer

Passengers

Physical layer

Structural Health Monitoring

Wireless Sensor Network

Copyright




Page 3

CHOSeN Public


Table of Contents

1 EXECUTIVE SUMMARY ..................................................................................................................6

2 INTRODUCTION ...............................................................................................................................7

3 AERONAUTIC APPLICATIONS .................................................................................................. 10

3.1

Crack-wire Monitoring for Supporting Structure .............................................. 12

3.2

Distributed Strain Monitoring of Hull Components ......................................... 12

3.3

Cargo and PAX Door Surrounding ................................................................................. 12

4 APPLICATION REQUIREMENTS ............................................................................................... 13

4.1

General ............................................................................................................................................... 13

4.1.1

Temperature.................................................................................................................................................. 13

4.1.2

Pressure........................................................................................................................................................... 13

4.1.3

Humidity ......................................................................................................................................................... 13

4.1.4

Water tightness ............................................................................................................................................ 13

4.1.5

Shock................................................................................................................................................................. 13

4.1.6

Vibrations ....................................................................................................................................................... 14

4.1.7

Chemical resistance .................................................................................................................................... 14

4.1.8

Others [ABD0100], [DO160F] ................................................................................................................ 14

4.1.9

Safety and Security ..................................................................................................................................... 14

4.2

Sensors ............................................................................................................................................... 16

5 USER REQUIREMENTS ................................................................................................................ 18

6 ARCHITECTURE & FUNCTIONAL MODEL ............................................................................. 19

6.1

Autonomous wireless sensor node (W) ................................................................... 20

6.2

Gateway node (G) ..................................................................................................................... 20

6.3

Central data collector (D) ................................................................................................... 21

6.4

Functional analysis ................................................................................................................... 21

6.4.1

F1 - Data Acquisition .................................................................................................................................. 22

6.4.2

F2 - Communication ................................................................................................................................... 23

6.4.3

F3 - System monitoring ............................................................................................................................. 25

6.4.4

F4 - Human machine interface ............................................................................................................... 26

6.5

System elements ........................................................................................................................ 28

7 SYSTEM REQUIREMENTS DEFINITION ................................................................................. 30

Copyright




Page 4

CHOSeN Public


List of figures

Figure 1: System & Structure Health Monitoring - Application Overview

.................. 10

Figure 2: Schematic overview of WSN architecture for SHM applications

................. 19

Figure 3: Wireless Sensor Node [CHOSeN DoW]

........................................................... 20

Figure 4: Functional Tree ......................................................................................................... 21

Figure 5: Data acquisition functional tree ................................................................................. 22

Figure 6: Communication functional tree .................................................................................. 23

Figure 7: System monitoring functional tree ............................................................................. 26

Figure 8: HMI functional tree .................................................................................................... 27

Table 1: Examples of physical parameters to monitor in different aircraft domains

11

Table 2: Design assurance level definition

...................................................................... 15

Copyright




Page 5

CHOSeN Public


1 EXECUTIVE SUMMARY

The present document aims on providing a general description of the aeronautic applications and to collect the corresponding system requirements that, together with the automotive requirements, shall serve as a guideline for the CHOSeN wireless sensor network design and development.

The

INTRODUCTION

section describes the general context of the aeronautic

applications, the motivation and expected impact on the operation and maintenance optimization.

The

AERONAUTIC APPLICATIONS

section provides a description of the

aeronautic applications, where the general characteristics are outlined and the implications on the development of the CHOSeN platform are highlighted.

The

APPLICATION REQUIREMENTS

section enumerates and analyses the

requirements regarding the sensors, communication, energy-consumption and functions.

The sections

USER REQUIREMENTS

and

ARCHITECTURE & FUNCTIONAL MODEL

enunciate the user requirements which have been identified in the phase of the application selection and describe the function of the systems components realizing the aeronautic demonstrator and briefly describes the main elements of the system.

The

SYSTEM REQUIREMENTS DEFINITION

section collects all the aeronautic

applications functional requirements emerged from the analysis done across the document. Starting from the CHOSeN general purposes described in the

DoW, aeronautic applications capable of challenging the CHOSeN platform has been identified and analyzed.

In this document the Applications description has been shortened in contrast to the corresponding section in D1.2b.

Copyright




Page 6

CHOSeN Public


INTRODUCTION

In order to observe and assure the safety, functions and life-time of certain components of aircrafts, a lot of physical data has to be collected, processed and matched with system models. These measurements are related for instance with the temperature impact over time on different critical parts, the pressure, distension and torsion of parts of the landing gear and so on.

Many of these measurements are done during the maintenance times of aircrafts; parts are disassembled, audited and possibly exchanged. The effort is huge and so are the costs of the maintenance times. So it is obvious that integrated system health monitoring could reduce both the time the airplane is maintained and disassembled as well as the maintenance costs.

It is also obvious that a lot of distributed measuring points with various functions are needed. These sensors will have different requirements in terms of power consumption, vibration and shock tolerance, etc. They will also have different capabilities in terms of data priority, data rate, latency and frequency. Some of these sensors could certainly be wired, while others can only be wireless due to their positioning. There are a lot of different aircrafts and aircraft configurations, and the future will certainly bring new maintenance models demanding more measurement points and/or other physical input. Therefore, it is desired to have a general communication infrastructure, including the sensor nodes, communication protocols and data collecting and presentation platform.

The sensor nodes should be able to organise themselves. That means that they “speak a common language”, are able to find among each other’s and to find ways to distribute their data in the sensor network. Some of these features are not needed for all types of sensors, and some sensors might not even have the power to perform all these tasks. Therefore the general sensor node platform must be programmable and configurable. A common platform for all types of sensors does also have additional advantages:

 Only one type of hardware to test and verify

 Easy design of new sensor components

 Low-cost because of high number of units

 Flexibility and scalability

The general sensor node design and communication platform would even allow using the same base system for structure health monitoring in other industrial fields.

Maintenance work on an aircraft is triggered by two usually disjoints events: unscheduled events raised by failures or malfunctions and scheduled events, which are regular maintenance. A typical relation between “unscheduled events” and “scheduled events” is respectively 60% to 40% on an events basis. The related maintenance efforts may differ, but grounding times split close to that ratio. Needless to say that unscheduled events lead to

Copyright




Page 7

CHOSeN Public

Deliverable: D1.2a Requirements analysis document for aeronautic applications V1.1 unplanned (even if somehow expected: 60%) grounding times during regular use costing aircraft carriers a lot of money and reputation.

Unscheduled events are split in turn in normal wear related maintenance

(=lighter checks) and the heavier checks asked for by the certification authorities. Aircraft maintenance checks are periodic checks that have to be done on all aircraft after a certain amount of time or usage. Airlines refer to these checks as one of the following: A check, B check, C check, or D check.

A and B checks are lighter checks, while C and D are considered heavier checks.

 A Check — this is performed approximately every month. This check is usually done overnight at an airport gate. The actual occurrence of this check varies by aircraft type, the cycle count (takeoff and landing is considered an aircraft "cycle"), or the number of hours flown since the last check. The occurrence can be delayed by the airline if certain predetermined conditions are met.

 B Check — this is performed approximately every 3 months. This check is also usually done overnight at an airport gate. An occurrence schedule similar to the one of the A check applies to the B Check.

 C Check — this is performed approximately every 12-18 months. This maintenance check puts the aircraft out of service and requires plenty of space - usually at a hangar at a maintenance base. The schedule of occurrence has many factors and components as has been described, and thus varies by aircraft category and type.

 D Check — this is the heaviest check for the airplane. This check occurs approximately every 4-5 years. This is the check that, more or less, takes the entire airplane apart for inspection. This requires even more space and time than all other checks, and must be performed at a maintenance base.

The use of WSN technology would enable the transfer of interventions from unscheduled maintenance to scheduled maintenance. At the same time the engineer would get feedback to replace unreliable spare parts by better ones. Therefore the closed loop to engineering is another major point.

The future is also to deal with certification authorities for maintenance on demand based on predictive models for unscheduled events plus A and B checks in order to break the rigid maintenance schedule scheme. To reach this goal, detailed and reliable data are needed “for all” LRIs, structures and system components.

The main benefits of this continuous monitoring with wireless, or rather "less wired", sensor networks and the targeted new maintenance and operation concept are:

Simpler installation

Less initial cost (bill of materials)

Less weight

Copyright




Page 8

CHOSeN Public


Less volume

Higher reliability

Easier troubleshooting

Easier re-configuration

Low spares cost

For the end user that means:

Lower costs

Better comfort and service

Higher safety and reliability

Copyright




Page 9

CHOSeN Public


2 AERONAUTIC APPLICATIONS

This chapter gives a short overview of the general scope of the applications for system and structure health monitoring in the aeronautic industry and the benefits that are expected for the whole aircraft operation processes – not only for the aircraft production – but also for the operators (e.g. the airlines), the OEM and MRO (Maintenance, Repair and Overhaul) services.

Figure 1 shows the general idea of distributed monitoring of various aircraft

systems and parameters and the expected impact and benefits for the aircraft itself (left side) and the operator of the aircraft (right side). Single sensors are already integrated in current aircrafts and connected to existing communication infrastructure. Other sensors are only applied when the aircraft is on-ground or even partly disassembled for maintenance.

Continuous monitoring of the health state of various systems and structure is not yet possible. structures engines power hydraulics electronics sensors data sensors data sensors data sensors data sensors data fatigue model engine model power system model hydr. model electr. wear model

Wired -> Wireless:

• Save cables

• Save weight

• Minimize power consumption

• Easy installation & maintenance

• Flexibility & Scalability

Enables Predictive Maintenance:

• Minimize On-Ground Time

• Save Disassembly Times

• Increase Safety

• Optimize airplane operation processes

• Save money

Figure 1: System & Structure Health Monitoring - Application Overview

The benefit that is expected from continuous monitoring of very different and distributed physical parameters is ultimately cost saving. These savings are expected mainly in the installation, maintenance and operation as

explained Chapter 0.

In an aircraft there are a lot of different systems in various compartments where several different physical parameters are measured or are at least

Copyright




Page 10

CHOSeN Public

Deliverable: D1.2a Requirements analysis document for aeronautic applications V1.1 desired. A common measurement/monitoring infrastructure does not exist in the aircraft since most systems are designed independent.

Table 1 gives an overview of a number of physical parameters that are

measured in different compartments of an aircraft. The number of applications that depends on the monitoring of these parameters is very high and covers a broad spectrum of aircraft systems.

Aircraft Domain

Physical Parameter

Aerodynamics Cabin Engine Structure

Temperature

Pressure















Gas

Flow

Humidity

Fire

Vibration

Proximity

Displacement

Strain

































Table 1: Examples of physical parameters to monitor in different aircraft domains

For maximum benefit - as explained in the previous chapter - all parameters shall be acquired, communicated, evaluated and stored by a common infrastructure and provided for maintenance and operation purposes in a central database/computer within the aircraft. The process of the identification of applications for WSN and their exact requirements is currently ongoing within the aeronautic industry and by no means finished yet. However, it is already apparent from the hitherto existing analysis that a certain set of requirements is common for all applications. In the following three specific applications are described which seem to be both promising and challenging in terms of requirements to the WSN to be developed within

CHOSeN. The applications are selected so that the requirements cover a broad spectrum in order to meet the wide range of SHM applications.

Afterwards, in Chapter 4, the requirements are derived and analysed.

Copyright




Page 11

CHOSeN Public


2.1

Crack-wire Monitoring for Supporting Structure

Crack-wires are simple sensors, which require not much effort from the actual sensor hardware side, and at the same time are very useful for the monitoring of cracks and crack growth in supporting structure elements. In case of cracks caused by overload the crack-wire breaks. This can be measured by electrical continuity. The energy consumption of the sensor itself is very low and thus suited for use with autonomous wireless sensor nodes.

[shortened description for public release]

2.2

Distributed Strain Monitoring of Hull Components

Another possibility to assess the health of structure elements is to measure the strain (and temperature) continuously and apply certain aging models in order to predict the remaining lifetime of these structure elements. In principle there are three events that could induce extraordinary strain in the structure: (hard) landing, impact (e.g. bird strikes) and turbulences. If the exceeds certain thresholds, these events must be detected at the sensor locations in the structure and logged for later fusion and evaluation.


2.3

Cargo and PAX Door Surrounding

The surrounding of the passenger and cargo doors is subject to additional stress induced by the docking of aerobridges and gangways.


Copyright




Page 12

CHOSeN Public


3 APPLICATION REQUIREMENTS

3.1

General

Certain general requirements are to be met in order to justify the use of wireless sensors for maintenance optimisation. Especially the harsh environment conditions within an aircraft and the long projected lifetime (in the range of 30-50 years) are key requirements since it doesn't make sense to have maintenance helpers which need maintenance more often than the components they are monitoring.

Following requirement regarding the environment are general and basically based on the Airbus Directives and Procedures ABD0100.1.2 as well as the

RTCA/DO-160F, Environmental Conditions and Test Procedures for Airborne

Equipment. Only in exceptional cases for special scenarios other requirements can be valid.

However, since CHOSEN is a research project, these requirements are only established here as background information that should be kept in mind during development so that later production of airborne equipment is feasible at all.

3.1.1

Temperature

Operating temperature:

Survival temperature range:

Temperature changing rate:

3.1.2

Pressure

Minimum environmental pressure:

Maximum environmental pressure:

Decompression rate:

-55°C … +70°C

-55°C … +85°C

10°C/min

0.1bar

2.0bar

< 15Sek

(50.000ft)

3.1.3

Humidity

Relative humidity:

3.1.4

Water tightness

Water tightness:

3.1.5

Shock

Maximum shock load:

95  4 % at 55°C splash watertight (DO-160F Sec. 10 Cat. S)

20g, 11ms (all 6 directions)

Copyright




Page 13

CHOSeN Public


3.1.6

Vibrations

Frequency range:

Level:

Spectral distribution:

10 … 2000Hz

7.9 g rms (1g = 9.81m/s²)

10 – 28Hz:

40 – 100Hz:

0.02g²/Hz

0.04g²/Hz

200 – 500Hz:

– 2000Hz:

0.08g²/Hz

-6dB/oct

3.1.7

Chemical resistance

Chemically resistant against:

Fuel:

Hydraulic fluid:

Aviation Jet Fuel Type A (Kerosene)

H537 / Skydrol

Lubricant:

Solvents:

Defrosting fluid:

Insecticide:

Wastewater:

Saline water:

O-133 (petroleum base)

Denatured alcohol

Nato S-735 (DTD406B)

Dichlorvos (DDVP)

Dishwater/suds

NaCl dilution (5%)

3.1.8

Others [ABD0100], [DO160F]

Resistance against:

Fire/flammability

Sand/dust

Fungal attack

Icing

Electrostatic discharge

Radiation

3.1.9

Safety and Security

From the functional point of view the applications must be analyzed regarding the Design Assurance Level (DAL) of the system. These levels can then be used as guidelines for the communication safety, reliability and security analysis.

The required Design Assurance Level (DAL) is determined from the safety assessment process and hazard analysis by examining the effects of a

Copyright




Page 14

CHOSeN Public

Deliverable: D1.2a Requirements analysis document for aeronautic applications V1.1 failure condition in the system. The failure conditions are categorized by their effects on the aircraft, crew, and passengers.

Catastrophic: Failure may cause a crash.

Hazardous: Failure has a large negative impact on safety or performance, or reduces the ability of the crew to operate the plane due to physical distress or a higher workload, or causes serious or fatal injuries among the passengers.

Major:

Minor:

No Effect:

Failure is significant, but has a lesser impact than a hazardous failure (for example, leads to passenger discomfort rather than injuries).

Failure is noticeable, but has a lesser impact than a major failure (for example, causing passenger inconvenience or a routine flight plan change)

Failure has no impact on safety, aircraft operation, or crew workload.

DAL

A

B

C

D

E

Failure condition

Catastrophic

Hazardous

Major

Minor

No effect

Table 2: Design assurance level definition

According to the DAL the requirements on the communication regarding safety, reliability and security can be done.

The applications considered in

CHOSeN are only DAL E and maybe D. Therefore, the highest priority should be on: reliability, authenticity, integrity. Data loss or corrupted/wrong data have to be avoided and would be considered a security breach. On the other hand, the additional power consumption required for security measures should be as low as possible, since the energy availability at the sensor node side is one of the bottlenecks. But since the transmitted information only needs to be kept secret for several days, the performance (resistance to deciphering) shouldn’t be the highest priority. This is also supported by the fact that the processing power available at the sensor nodes is very limited due to the low power microcontroller needed there.

The environment in which the communication takes place is only inside the aircraft, external links are not involved. The equipment involved in the communications is static, no mobile devices and their special security challenges have to be considered.

The trade-off between storage and transmission of data regarding the energy-consumption is a key parameter of the considered SHM applications.

For instance, a lot of measurements could be aggregated and stored for just one transmission later. However, the stored data should also be protected against alteration and unauthorized access.

Copyright




Page 15

CHOSeN Public


Since the ultimate goal of the continuous structure health monitoring are structure-embedded sensor nodes, these nodes are hard (rather impossible) to reach for maintenance issues. Thus, remote configuration and possibly secret key (re-)distribution should be possible. Considering the long lifetime of the sensor nodes the progress in deciphering methods of currently unbreakable encryption algorithms should be taken into account. That means that 20 years in the future for instance AES could be broken which in turn means that it should be possible to change the encryption method by means of remote software update.

3.2

Sensors

The applications described in Chapter 2 require three groups of sensors:

crack-wire

temperature/humidity

strain gage/acceleration

The crack-wires are unproblematic regarding the requirements. Thus, only the temperature and strain gage sensors are covered here.

Strain gage sensor

Measuring range

The measuring range of the strain gage sensor shall be  8000µm/m.

Resolution

The resolution shall be 2µm/m.

Accuracy

The absolute accuracy over the whole measurement and operating temperature range shall be  10µm/m.

Signal bandwidth

The maximum signal bandwidth shall be 2000Hz.

Offset drift

The tolerable offset drift shall not exceed  10µm/m / 24h.

Temperature measurement and compensation shall be possible.

Temperature sensor

Accuracy

The required accuracy of the temperature measurement is  0.5°C

Copyright




Page 16

CHOSeN Public


Resolution

The required resolution is 0.1°C.

Energy consumption

The energy consumption per sensor element shall be < 200µW.

Supply voltage

< 2.5V

Copyright




Page 17

CHOSeN Public


4 USER REQUIREMENTS

The aeronautic applications have been selected by taking into account the needs from Airbus departments working in the area of system and structural health monitoring regarding functionality to be provided under the constraints of the aircraft environment.

The identified user requirements are hereby listed:

UR1. The applications must report the health state of the monitored system and structure components.

UR2. The a communication system must be reliable, scalable in terms of the number of supported data sources, and low power consuming to enable long-term autonomous operation of embedded sensors.

UR3. The applications must be configurable by the user (e.g. adapt thresholds)

UR4. The application must not be limited by the current aircraft architecture; if necessary, it must be possible to add new nodes enabling new functionalities

UR5. The application must rely on a communication infrastructure, which takes into account the economical impact of its realization.

Copyright




Page 18

CHOSeN Public


5 ARCHITECTURE & FUNCTIONAL MODEL

The aeronautic applications described in Chapter 2 require following

components for the Wireless Sensor Network (more specific Sensor Network with less wires): a Wireless sensor node as described in [CHOSeN DoW] which should be able of autonomous (energy-harvester driven) operation, a

Gateway node with reliable power supply and backbone access, and a

central maintenance support database. Figure 2 shows a schematic overview

of the network and its components.

Figure 2: Schematic overview of WSN architecture for SHM applications

The functionalities of the single components are described in the following whereas their interfaces are described in the aeronautic demonstrator specification document.

Copyright




Page 19

CHOSeN Public


5.1

Autonomous wireless sensor node (W)

A wireless sensor node as shown in

Figure 3 consists mainly of the

microcontroller (with analogue and digital sensor interfaces), the wake-upradio, the transceiver and the power management. One or more sensors of the same or different types can be connected to such a wireless node.

Battery or

Scavenging

Radio

Transceiver

Wakeup Radio

Oscillators &

Wakeup

Controller

Microcontroller

Upper Layer

Protocols

MAC

Layers

Protocol

Processing

Engine

Reconfigurable Logic

Energy Supply

Management

Node Power

Management

Analog

Sensor-

Actuator

Interface

SIP/SoC Implementation

Oscillator

Sensor

Within main Project objectives

Figure 3: Wireless Sensor Node [CHOSeN DoW]

Wireless nodes should be capable of autonomous work for several 10th of years. That means they need an interface to energy harvesting devices like thermal elements, solar, vibration harvesters. Alternatively they should be able to work with batteries or even regular electrical power supply (28V).

They also need non-volatile storage like flash memory. The transceiver, amplifier, sensor interfaces, microcontroller should be optimised regarding power consumption and be switched off and on separately. A worldwide unique identifier must be accessible by each wireless sensor node. A secret key must be replaceable stored.

5.2

Gateway node (G)

Gateway nodes do not need sensor interfaces and power management functionality since they have direct connection to the power supply of the aircraft backbone. Their power amplifier, transceivers and CPU don't need to be optimized regarding power consumption. Thus they are much more powerful than Wireless Sensor nodes. Additionally these Gateways have an interface to the aircrafts data backbone (CIDS, AFDX) and much more volatile and non-volatile memory than the wireless sensor nodes. The

Gateway must be capable of waking up single Sensor nodes without interfering with other (sleeping) Sensor nodes and collecting their data and configuring their operation (measurement, threshold, processing and communication parameters).

Copyright




Page 20

CHOSeN Public


5.3

Central data collector (D)

The central database is a computer in the aircraft with reliable power supply and enough storage and computational power to execute all communication, storage and processing tasks involved with the SHM applications described.

In addition it has an interface to the aircraft data backbone and an external interface to the maintenance and operations personnel outside the aircraft.

For the sake of simplicity, the Central data collector will also serve as the

Application server for demonstration purposes. That means there will be a user interface, which allows the configuration, monitoring of the sensor node and network states and the display of the fused and interpreted measurement data.

5.4

Functional analysis

The description of the services expected by the user leads to the building of the hierarchical functional tree. A function describes an aspect of the system behaviour regardless of the way it is internally accomplished. The functional tree represents the main functions of the system with their interconnection in a modular and hierarchical tree.

As represented in the functional tree (

Figure 4

), the main functionalities of

the system are:

 F1 – Data Acquisition: provides data coming from the sensors

 F2 – Communication: provides a communication system compliant with the application needs

 F3 – System Monitoring: monitors of the system and the components

 F4 – Human Machine Interface: configuration, reporting & display

Functional Tree

F1 - Data Acquisition

F2 - Communication

F3 - System Monitoring

F4 - Human Machine Interface

Figure 4: Functional Tree

Copyright




Page 21

CHOSeN Public


5.4.1

F1 - Data Acquisition

This functionality provides a set of data coming from the heterogeneous set

of sensors. As represented in the functional tree (

Figure 5

) the main sub-

functionalities related to the function F1 – Data Acquisition are hereafter listed:

 F1.1 – Stringer health status measurements

 F1.2 – Hull components health status measurements

 F1.3 – Door surrounding structure impact intensity measurements

Functional Tree


F1.1 - Stringer health

F1.2 - Hull components health

F1.3 - Door surrounding health

F2 - Communication



Figure 5: Data acquisition functional tree

F1.1 – Stringer health status measurements

The stringer health assessment is done by attached crack-wire sensors and optionally attached temperature and humidity sensors. The crack-wires detect cracks under the structure part where they are attached. The optional temperature and humidity sensors deliver data, which can be used to estimate possible damage due to corrosion.

F1.2 – Hull components health status measurements

The load, which is imposed on the hull structure, is measured by strain gage sensors and can be used to estimate possible damage.

F1.3 – Door surrounding structure impact intensity measurements

Copyright




Page 22

CHOSeN Public


Impacts of gateways or airbridges are detected by acceleration sensors and the measured data can be used to estimate the health status of the door surrounding structure.

5.4.2

F2 - Communication

This functionality provides a reliable, secure, scalable and adaptable system for transmission and reception of data through the wireless network. As

represented in the functional tree (

Figure 6

) the main sub-functionalities

related to the function F2 – Communication are hereafter listed:

 F2.1 – Auto-configuration

 F2.2 – Wake-up MAC

 F2.3 – Protocol scalability

 F2.4 – Secure data transport

Functional Tree


F2 - Communication

F2.1 - Auto configuration

F2.2 - Wake-up MAC

F2.3 - Protocol scalability

F2.4 - Data transport



Figure 6: Communication functional tree

F2.1 – Auto-configuration

The automatic configuration functionality makes the network capable of selforganization, which translates into the following basic functionalities of each node:

 Initial setup of a new network

 Addition/deletion of a node to/from the network

Copyright




Page 23

CHOSeN Public


 Awareness of the local network topology

 Path reorganization according to the network topology changes due to access point changes or node add/del.

F2.2 – Wake-up MAC

The multi MAC wake-up functionality enables a tuneable node wake-up functionality. A node in idle state, for energy saving purposes, can be woken up by another network component and start a communication, which is optimized for a particular data exchanged. Additionally, the different sensors have different functions: e.g., the crack-wires are only polled by the access points in very seldom circumstances while the acceleration sensors must be woken up during gateway approach and transmit their data continuously afterwards. The MAC must be capable of handling these communication behaviours together with the wake-up functions involved.

F2.3 – Protocol scalability

The protocol scalability functionality enables an energy-optimized transmission system, according to the type of data to transmit. To each communication profile a corresponding QoS is associated.

For instance the specific requirements of a temperature sensor yield a QoS characterized by low data transmission and high latency tolerance, while an acceleration sensor linked to critical data transmission could determine a

QoS with lower latency transmission.

Another task is the support of a varying number of sensor nodes with different data rates and transmission behaviour.

F2.4 – Secure data transport

The data transmission functionality (and its consequent data reception) is the core function of the communication system by mean of which the information circulates through the network. The design of the communication system is data oriented, i.e. it starts from the characteristics of data distributed (and required) in the network, and power supply aware, i.e. in the case of sensors operated by energy-harvesting devices.

Security

The security function is not bound to a particular usage scenario, the automotive and aerospace application domains are presented to better understand the special needs in the particular domain but the system is not limited only to these domains.

The system must protect the over the air transmitted information, data stored in node’s memory and the interfaces that allow reading, modification and configuration of the WSN.

Though the impacts of threats of the target of security are considered only from category DAL D/E (Major) in the considered aeronautic applications,

Copyright




Page 24

CHOSeN Public

Deliverable: D1.2a Requirements analysis document for aeronautic applications V1.1 higher DAL applications must be supported, since they could (and should) be added later.

The priorities taken into account in the security features design are the following in this order:

1. Reliability

2. Authenticity

3. Integrity

4. Performance

5. Energy consumption

The protected information is the ID of sending node, the timestamp and at least some fields of the payload.

5.4.3

F3 - System monitoring

This functionality gives the visibility of the status of the network, in terms of links between the nodes, paths, and the acquired data from the displaced sensor. Moreover it provides the monitoring of the systems/components health state.


Figure 7

), the main sub-functionalities

related to the function F3 – System monitoring are hereafter listed:

 F3.1 – Sensors state monitoring

 F3.2 – Network state monitoring

 F3.3 – Systems state monitoring

Copyright




Page 25

CHOSeN Public


Functional Tree


F2 - Communication


F3.1 - Sensors state

F3.2 - Network state

F3.3 - Systems state


Figure 7: System monitoring functional tree

F3.1 – Sensors state monitoring

This function enables the system to get the state of the sensors itself, that means if they are still working, their configured thresholds, their calibration and the state of their energy source.

F3.2 – Network state monitoring

The network monitoring functionality shows the network working status. I.e. it provides network wake up in case of a (re-)configuration event and regulates its performance in order to maximize the network reactivity according to the number of wireless nodes and reachable access points.

F3.3 – Systems state monitoring

This function enables the prediction of the health state of the monitored structure components and systems by collecting the measurements, fusing and processing these values and estimating and signaling their health status.

5.4.4

F4 - Human machine interface

The HMI functionality provides information to the user via a GUI for the system monitoring and enables the configuration of several aspects of the data acquisition and communication.


Figure 8

), the main sub-functionalities

related to the function F4 – Human Machine Interface are hereafter listed:

Copyright




Page 26

CHOSeN Public


 F4.1 – Configuration

 F4.2 – Network state reporting

 F4.3 – Systems health state reporting

Functional Tree


F2 - Communication



F4.1 - Configuration

F4.2 - Network state reporting

F4.3 - Systems state reporting

Figure 8: HMI functional tree

F4.1 – Configuration

The configuration function enables the user to control several aspects of the monitoring system including the sensors (e.g. thresholds, sampling interval), the communication parameters (e.g. polling intervals, priorities) and the reporting intervals.

F4.2 – Network state reporting

This function enables the user to monitor the number and state of the sensor nodes, their connectivity, energy source and communication parameters. The transport paths (via access points) and their capacity and quality are also visualized.

F4.3 – Systems health state reporting

Finally, this function provides the user the desired health state information of the monitored systems. For this purpose, the collected data are fused, processed and interpreted to give a health assessment of the systems and structure components monitored.

Copyright




Page 27

CHOSeN Public


5.5

System elements

The system, which realizes the aeronautic applications, is composed of the following sub-systems:



SE_1 - Data Acquisition System



SE_2 - Communication System



SE_3 - Data Processing System



SE_4 - Human Machine Interface

SE_1 Data Acquisition System

The Data Acquisition System realizes the functions linked to the measurement of the systems characteristic parameters. It is composed of two main components:



The sensory system addresses the acquisition of the parameters, which are needed by the application (see F1.1, F1.2, F1.3). The diversification of the measure types entails the heterogeneity of the involved sensors (crack-wire, acceleration, temperature, humidity, strain)



The data conversion system takes the output signal from the sensors and converts it into the digital format, which is the suitable input of the data processing system. The data conversion system is customized for each sensor class, by implementing the adequate HW/SW interfaces

SE_2 Communication System

The Communication System realizes the communication functions (see F2) enabling the interconnection between the CHOSeN system components. It can be separated into the following components:



Wake-Up radio, that wakes up the node, when it is needed by the application. The design of this module is part of task 3.1, where it will be investigated the integration of low-power idle channel listening blocks, which might be operated semi-passive at extremely low power levels



Radio Transceiver , that is involved in case of message transmission or message reception among CHOSeN nodes. The definition, design and implementation of this component is the aim of Task 3.2, whose objective is to provide an adaptable transceiver architecture supporting a variety of frame formats and wake-up paradigms



Communication Gateways towards external devices, which enables the interoperability of the CHOSeN WSN with other communication standards (CAN BUS,

AFDX, ARINC, ...)

SE_3 Data Processing System

Copyright




Page 28

CHOSeN Public


The Data Processing System realizes the data fusion and processing algorithms and implements the monitoring and control logic, which are part of the aeronautic applications. It consists of the following components:



Local processing nodes, where the in-node data fusion and processing algorithms are implemented in order to generate reliable measurements and status information



Main control nodes, realized as access points to a wired infrastructure, therefore characterized by a high computational power and with no power supply constraints. The main system logic is implemented on this type of node: the communication system monitoring (network state, network performance, network configuration), the aeronautic application control (thresholds, communication parameters, states) and the global system management.

SE_4 Human Machine Interface

The HMI provides information to the user and enables the control and configuration of the system. It consists mainly of the following components:



Database: sensors, locations, thresholds, energy source states, id, time, values, ...



GUI: configuration, monitoring and control of all aspects of the application components

Copyright




Page 29

CHOSeN Public


6 SYSTEM REQUIREMENTS DEFINITION

The application analysis leads toward the system functional and technical requirements definition for the aeronautic applications, which are summarized in Table 3. Each requirement is described by its



Code, alphanumerical expression that allows identifying the requirement. Each re quirement is preceded by “AeSR”, meaning Ae=Aeronautic, S=system, R=requirement



User Requirement, specification of the user requirements that can be linked to the requirement (reference of the father user requirement)



Priority, level of priority of the requirement. Possible values are H=High, M=Medium,

L=Low



Description, short textual description of the requirement



Validation, method of validation by mean of which the fulfilment of the requirement can be validated. Possible value are T=Test, A=Analysis, S=Simulation



Elements, list of the element of the system that are involved in case of requirement satisfaction



Functionality, specification of the high level functionalities, which are linked to the requirement.

It is important to highlight that the aeronautic requirement list must be validated with the WP2/WP3 outcomes; therefore it must be reviewed and agreed.

Code

User

Req.

Priority

(H/M/L)

Description

Validation

(T/A/S)

Element

Function

AeSR_1 UR_1 H

The system must acquire the data needed to estimate the stringers health

T SE_1 F1

AeSR_2 UR_1 H

The system must acquire the data needed to estimate the hull components health

T SE_1 F1

AeSR_3 UR_1 H

The system must acquire the data needed to estimate the door

T SE_1 F1

Copyright




Page 30

CHOSeN Public


Code

User

Req.

Priority

(H/M/L)

Description

Validation

(T/A/S)

Element surrounding structure health

Function

AeSR_4

AeSR_5

AeSR_6

UR_1

UR_1

UR_1

H

H

H

The acquired sensor data must be with the specified accuracy & resolution

The acquired data must be stored in non-fluid memory in the wireless node

The system must provide the interfaces necessary to connect the specified sensors

T

T/A

T/A

SE_1

SE_1

SE_1

F1

F1

F1

AeSR_7

AeSR_8

AeSR_9

UR_2

UR_2

UR_2

AeSR_10 UR_2

H

H

M

M

The communication system must support a reliable data communication

The communication system must support synchronized communication

The communication system must provide a redundant channel

The communication system must have an interface towards the aircrafts wired backbone

T/S

T/S

T/A

T/A

SE_2

SE_2

SE_2

SE_2

F2

F2

F2

F2

Copyright




Page 31

CHOSeN Public


Code

User

Req.

Priority

(H/M/L)

Description

Validation

(T/A/S)

Element

AeSR_11 UR_2 H

The communication system must be capable of automatic setup/ initialization

T/S SE_2

Function

F2

AeSR_12

AeSR_13

AeSR_14

UR_2

UR_4

UR_2

UR_4

UR_2

UR_4

H

H

H

The wireless network must be able to add new nodes

The wireless network must be able to delete nodes

The wireless network must support the specified communication modes (poll, event)

T/S

T/S

T/S

SE_2

SE_2

SE_2

F2

F2

F2

AeSR_15 UR_2

AeSR_17 UR_2

AeSR_18 UR_2

H

H

H

M

The wireless nodes components must be able to be separately switched on/off

The communication system must support prioritization

The communication system must be able to detect and communicate the energy source state

The communication system must support energyharvesting driven nodes

T/A

T/S

T/S

T/S

SE_2

SE_2

SE_2

SE_2

F2

F2

F2

F2

Copyright




Page 32

CHOSeN Public


Code

User

Req.

Priority

(H/M/L)

Description

Validation

(T/A/S)

Element

AeSR_19 UR_2 M

The communication system must be able to address single nodes via the

WUR

T/A SE_2

Function

F2

AeSR_20 UR_1

AeSR_21 UR_1

H

H

The system must be able to process and fuse data locally

The system must be able to process and fuse data in the access points

T/S

T/S

SE_3

SE_3

F3

F3

AeSR_22 UR_1

AeSR_23 UR_3

AeSR_24 UR_3

AeSR_25 UR_3

AeSR_26 UR_1

AeSR_27 UR_1

H

H

H

H

H

H

The system must be able to predict the health state of the monitored components

The system must be able to configure the sensors

The nodes must store their configuration and state

The HMI must provide facilities to configure the specified parameters

The system must store the specified states, values and parameters in a central database

The system must display the

T/A

T/A

T/A

T

T

T

SE_3

SE_2

SE_4

SE_1

SE_4 F1..F4

SE_4

SE_4

SE_4

F3

F2-F4

F4

F4

F4

Copyright




Page 33

CHOSeN Public


Code

User

Req.

Priority

(H/M/L)

Description

Validation

(T/A/S)

Element specified states, values on a GUI

Function

AeSR_28 UR_2 H

The system must provide secret key distribution, storage and encryption methods to provide the demanded security levels

A

SE_2

SE_3

SE_4

F2..F4

Table 3: System requirements definition table

Copyright




Page 34

CHOSeN_D1_2a_Aeronautic Requirements analysis document (PU)

Cooperative Hybrid Objects Sensor Networks

CHOSeN

Project Report

Referenced Documents

Abbreviation List

Table of Contents

List of figures

1 EXECUTIVE SUMMARY

INTRODUCTION

2 AERONAUTIC APPLICATIONS

3 APPLICATION REQUIREMENTS

4 USER REQUIREMENTS

5 ARCHITECTURE & FUNCTIONAL MODEL

Functional Tree

Functional Tree

6 SYSTEM REQUIREMENTS DEFINITION

Related documents

Products

Support

CHOSeN_D1_2a_Aeronautic Requirements analysis document (PU)

Cooperative Hybrid Objects Sensor Networks

CHOSeN

Project Report

Referenced Documents

Abbreviation List

Table of Contents

List of figures

1 EXECUTIVE SUMMARY

INTRODUCTION

2 AERONAUTIC APPLICATIONS

3 APPLICATION REQUIREMENTS

4 USER REQUIREMENTS

5 ARCHITECTURE & FUNCTIONAL MODEL

Functional Tree

Functional Tree

6 SYSTEM REQUIREMENTS DEFINITION

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib