CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close

Cooperative Hybrid Objects Sensor Networks

Contract Number: INFSO-ICT-224327

Copyright CHOSEN Consortium 2008-2011

DELIVERABLE NO D1.2b

DELIVERABLE TITLE Requirements analysis document for the aeronautic applications

AUTHOR Jirka Klaue (EADS)

PEER REVIEWER

DATE SUBMITTED 15.09.2009

CHOSeN

Project Report

CHOSeN

Deliverable D1.2b: Requirements analysis document for the

aeronautic applications

Copyright CHOSEN Consortium 2008-2011 Page 2

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

CHOSeN




Abbreviation List

AFDX Avionics Full Duplex Ethernet

CFRP Carbon Fiber Reinforced Polymer

CIDS Cabin Intercommunication Data System

CRP Carbon Fiber Reinforced Plastic

CW Crack-Wire

LRI Line Replaceable Item

LRU Line Replaceable Unit

MAC Media Access Control

MRO Maintenance, Repair and Overhaul

MTTF Mean Time to Failure

NDT Non Destructive Testing

OEM Original Equipment Manufacturer

PAX Passengers

PHY Physical layer

SHM Structural Health Monitoring

WSN Wireless Sensor Network

CHOSeN




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.........................................14 3.3 Cargo and PAX Door Surrounding.................................................................................15

4 APPLICATION REQUIREMENTS...............................................................................................18 4.1 General ...............................................................................................................................................18

4.1.1 Temperature.................................................................................................................................................. 18 4.1.2 Pressure........................................................................................................................................................... 18 4.1.3 Humidity ......................................................................................................................................................... 18 4.1.4 Water tightness ............................................................................................................................................ 18 4.1.5 Shock................................................................................................................................................................. 18 4.1.6 Vibrations ....................................................................................................................................................... 19 4.1.7 Chemical resistance.................................................................................................................................... 19 4.1.8 Others [ABD0100], [DO160F] ................................................................................................................ 19 4.1.9 Safety and Security ..................................................................................................................................... 19

4.2 Sensors...............................................................................................................................................21

5 USER REQUIREMENTS................................................................................................................23

6 ARCHITECTURE & FUNCTIONAL MODEL.............................................................................24 6.1 Autonomous wireless sensor node (W)...................................................................25 6.2 Gateway node (G) .....................................................................................................................25 6.3 Central data collector (D) ...................................................................................................26 6.4 Functional analysis ...................................................................................................................26

6.4.1 F1 - Data Acquisition.................................................................................................................................. 27 6.4.2 F2 - Communication ................................................................................................................................... 28 6.4.3 F3 - System monitoring............................................................................................................................. 30 6.4.4 F4 - Human machine interface............................................................................................................... 31

6.5 System elements ........................................................................................................................33

7 SYSTEM REQUIREMENTS DEFINITION .................................................................................35

CHOSeN




List of figures

Figure 1: System & Structure Health Monitoring - Application Overview .................. 10 Figure 2: Schematic description of crack-wires.............................................................. 12 Figure 3: Example application of (wired) crack-wire sensors to upper fuselage of

aircraft............................................................................................................................ 13 Figure 4: Inside view of fuselage of Beluga aircraft ...................................................... 14 Figure 5: Aircraft on airport with aerobridge and gangway (right) and registered

positions of dents around doors (right).................................................................... 15 Figure 6: Typical structure around door from aircraft inside ....................................... 16 Figure 7: Schematic overview of WSN architecture for SHM applications ................. 24 Figure 8: Wireless Sensor Node [CHOSeN DoW] ........................................................... 25 Figure 9: Functional Tree ..............................................................................26 Figure 10: Data acquisition functional tree ......................................................27

Figure 11: Communication functional tree .......................................................28 Figure 12: System monitoring functional tree ..................................................31

Figure 13: HMI functional tree .......................................................................32

Table 1: Examples of physical parameters to monitor in different aircraft domains11 Table 2: Design assurance level definition ...................................................................... 20

CHOSeN




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.

CHOSeN




2 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

CHOSeN




close to that ratio. Needless to say that unscheduled events lead to

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)

CHOSeN




- Less weight

- 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

CHOSeN




3 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.

Fusion

structures

power

electronics

hydraulics

engines

sensors

sensors

sensors

sensors

sensors

data

data

data

data

data

fatigue model

engine model

power system model

hydr. model

electr. wear model

Enables Predictive Maintenance:

• Minimize On-Ground Time• Save Disassembly Times

• Increase Safety

• Optimize airplane operation processes

• Save money

Wired -> Wireless:

• Save cables• Save weight

• Minimize power consumption

• Easy installation & maintenance

• Flexibility & Scalability

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 2.

In an aircraft there are a lot of different systems in various compartments

where several different physical parameters are measured or are at least

CHOSeN




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.

CHOSeN




3.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. The principle is shown in Figure 2: one or more (for redundancy reasons) wires

are placed (printed, glued) over parts of structure elements that are subject to strain. 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.

Figure 2: Schematic description of crack-wires

Crack-wires seem to be a promising technique to continuously monitoring

the integrity of supporting structure and thus avoiding the periodically dismantling in order to assess the structural health in laboratories with NDT

methods, which is highly time-consuming and expensive.

Figure 3 shows a picture of a test installation of crack-wire sensors in the

ceiling of the A380 fuselage. They are installed on the stringers of the central upper fuselage.

CHOSeN




Figure 3: Example application of (wired) crack-wire sensors to upper fuselage of

aircraft

In this implementation case, there is no cabin dressing, no insulation

blanket, no air conditioning and no wiring. This has to be taken into account for wireless interrogation of these CW sensors.

The number of CW sensors needed for the monitoring the structural health

of the central upper fuselage depends of the actual aircraft type and its configuration. Thus it is not fixed. The reach of a wireless transmission in

this specific environment is also unknown yet and depends on a range of factors, like insulation, equipment and cabin installation, radio frequency,

antenna (integration), transmission power, receiver sensitivity and so on. That means that the number of data concentrator nodes (with access to the

backbone which is connected to the central maintenance computer) is also not fixed yet.

The interrogation of the sensors is activated on demand from the central maintenance computer. In the meantime, the sensor nodes shall not

transmit any data or signalling packets on its own. In order to acquire the status of the CW sensors it is necessary to activate the sensor nodes over

the air. The wake-on-radio functionality must be very low power while still providing the sensitivity to receive the wake-up signal in the challenging

environment.

The data rate of the transmission is very low since the state of the CW sensors will be acquired seldom (probably once a flight) and the amount of

data is not high (unique ID, state, time-stamp).

The latency/jitter requirements are very low, since it doesn't matter if the

state of the CW sensor is transmitted at an exact time. However, the data integrity and safety must be ensured.

CHOSeN




3.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.

For a better understanding of the continuous strain monitoring positions,

Figure 4 shows a picture of the inside of a fuselage of an aircraft where the strain gage sensors must be distributed (integrated). The exact number of

sensors depends on the aircraft and its configuration. Like in the CW sensor application the number of gateway nodes depends also on the wave

propagation conditions dictated by the frequency, power and environment.

Figure 4: Inside view of fuselage of Beluga aircraft

The measurements of the strain should take place when certain thresholds are exceeded. These thresholds must be (re-)configurable over the air. The

strain values should be stored together with a time-stamp. Also, the temperature must be measured periodically. The interval should also be

configurable. Data transmission could take place at any time, depending on the energy available, the storage level and wireless channel state. Data

fusion, compression and packet aggregation can be applied if necessary. This depends highly on the available bandwidth and should be considered

carefully since it might require a multi-hop capable communication protocol

CHOSeN




stack. The essential point is that all required data are transmitted to the

central database some day. Since the available power will probably be the crucial bottleneck, a trade-off has to be found between data processing

(microcontroller), data storage (e.g. flash memory) and data transmission (transceiver) energy consumption. This will be an interesting optimisation

problem once the boundary conditions are better known.

3.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. This is shown in Figure 5 with a picture of an aircraft on an airport with docked gangway

and aerobridge and an exemplary picture with registered dents around the PAX front door.

Figure 5: Aircraft on airport with aerobridge and gangway (right) and registered

positions of dents around doors (right)

In modern aircrafts more and more structure components are made of

composite materials like CFRP (carbon fiber reinforced polymer) or CRP (carbon fiber reinforced plastic). Unlike on metal components, impacts don't

manifest in visible dents. Instead, the damage results in small cracks or

delamination of composite layers. To avoid reinforcing of the endangered structure components, which would lead to higher weight (the whole point of

using composites instead of metal was weight reduction), the composite components should be monitored continuously to allow predictive

maintenance operations (e.g., installation of repair patches on damaged parts). The monitoring of the door surrounding during docking of gangways

or aerobridges with strain gage, acoustic emission and/or acceleration sensors and additional data fusion and model based damage evaluation

enables the prediction of necessary maintenance. Thus, unnecessary scheduled maintenance just in case can be avoided.

The measurements are event-based. In fact, this is special case of impact detection, which has other applications like bird strike at the engines or wing

CHOSeN




edges. However, that means that the measurements should be enabled

when a gangway is approaching the door. There are several methods, which can be used to wake up the sensor nodes to start the necessary

measurements: active antennas in the gangway could trigger passive RFID components in the sensor node, existing proximity sensors in the doors

could be abused or wake-on-radio transceiver capabilities of the sensor node itself could be triggered by transmissions from the gangway. All methods

have its advantages and disadvantages. Due to the fact that a common sensor platform for all applications should be developed, the method relying

on the wake-on-radio transceiver is preferred.

Figure 6 is included to give an insight where the sensors could be applied in

the aircraft for the door surrounding monitoring. The exact number and positioning of the sensor nodes depends again on the aircraft and on the

door (cargo, PAX, deck).

Figure 6: Typical structure around door from aircraft inside

The measured values should be fused, transmitted and evaluated as long as the aircraft is still on the ground or as soon as the aircraft has landed again.

Possible damages that could affect the door surrounding structure integrity and their location should be calculated. The estimated data rate required is

relatively high, but the latency and jitter requirements are not real-time.

That means, if the available bandwidth is not sufficient at any time, it can be traded off against delay (queuing/retransmissions) or even local storage in

the sensor nodes for later transmission.

CHOSeN




However, the same requirements as in the continuous strain monitoring

apply regarding the energy consumption. Once the boundary conditions of the energy consumption of the transceiver, microcontroller and non-fluid

storage are known, the data processing, storage and transmission can be optimized regarding power consumption which is the bottleneck when

talking about autonomous, maintenance-free sensor nodes.

CHOSeN




4 APPLICATION REQUIREMENTS

4.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.

4.1.1 Temperature

Operating temperature: -55°C … +70°C

Survival temperature range: -55°C … +85°C

Temperature changing rate: 10°C/min

4.1.2 Pressure Minimum environmental pressure: 0.1bar (50.000ft)

Maximum environmental pressure: 2.0bar

Decompression rate: < 15Sek

4.1.3 Humidity

Relative humidity: 95±4 % at 55°C

4.1.4 Water tightness

Water tightness: splash watertight (DO-160F Sec. 10 Cat. S)

4.1.5 Shock Maximum shock load: 20g, 11ms (all 6 directions)

CHOSeN




4.1.6 Vibrations Frequency range: 10 … 2000Hz

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

Spectral distribution: 10 – 28Hz: 0.02g²/Hz

40 – 100Hz: 0.04g²/Hz

200 – 500Hz: 0.08g²/Hz

– 2000Hz: -6dB/oct

4.1.7 Chemical resistance

Chemically resistant against:

Fuel: Aviation Jet Fuel Type A (Kerosene)

Hydraulic fluid: H537 / Skydrol

Lubricant: O-133 (petroleum base)

Solvents: Denatured alcohol

Defrosting fluid: Nato S-735 (DTD406B)

Insecticide: Dichlorvos (DDVP)

Wastewater: Dishwater/suds

Saline water: NaCl dilution (5%)

4.1.8 Others [ABD0100], [DO160F] Resistance against:

- Fire/flammability

- Sand/dust

- Fungal attack

- Icing

- Electrostatic discharge

- Radiation

4.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

CHOSeN




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: Failure is significant, but has a lesser impact than a

hazardous failure (for example, leads to passenger discomfort rather than injuries).

Minor: Failure is noticeable, but has a lesser impact than a major failure (for example, causing passenger inconvenience or a

routine flight plan change) No Effect: Failure has no impact on safety, aircraft operation, or crew

workload.

DAL Failure condition

A Catastrophic B Hazardous

C Major D Minor

E 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

CHOSeN




one transmission later. However, the stored data should also be protected

against alteration and unauthorized access. 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.

4.2 Sensors

The applications described in Chapter 3 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

CHOSeN




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

Resolution

The required resolution is 0.1°C.

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

Supply voltage

< 2.5V

CHOSeN




5 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.

CHOSeN




6 ARCHITECTURE & FUNCTIONAL MODEL

The aeronautic applications described in Chapter 3 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 7 shows a schematic overview of the network and its components.

Figure 7: 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.

CHOSeN




6.1 Autonomous wireless sensor node (W)

A wireless sensor node as shown in Figure 8 consists mainly of the microcontroller (with analogue and digital sensor interfaces), the wake-up-

radio, the transceiver and the power management. One or more sensors of the same or different types can be connected to such a wireless node.

Radio

Transceiver

Analog

Sensor-

Actuator

InterfaceNode Power

Management

Oscillators &

Wakeup

Controller

Wakeup Radio

Upper Layer

Protocols

Flexible

Baseband

MAC

Layers

Protocol

Processing

Engine

Reconfigurable Logic

Energy Supply

Management

SIP/SoC ImplementationRobustness

and Security

SensorBattery or

Scavenging

Within main Project objectives

OscillatorMicrocontroller

Figure 8: 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.

6.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).

CHOSeN




6.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.

6.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 9), 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 9: Functional Tree

CHOSeN




6.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 10) 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


F2 - Communication



F1.1 - Stringer health

F1.2 - Hull components health

F1.3 - Door surrounding health

Figure 10: 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

CHOSeN




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.

6.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 11) 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 11: Communication functional tree

F2.1 – Auto-configuration

The automatic configuration functionality makes the network capable of self-

organization, 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

CHOSeN




• 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,

CHOSeN




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.

6.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.

As represented in the functional tree (Figure 12), 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

CHOSeN




Functional Tree


F2 - Communication



F3.1 - Sensors state

F3.2 - Network state

F3.3 - Systems state

Figure 12: 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.

6.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.

As represented in the functional tree (Figure 13), the main sub-functionalities

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

CHOSeN




• 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 13: 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.

CHOSeN




6.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

CHOSeN




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

CHOSeN




7 SYSTEM REQUIREMENTS DEFINITION

The application analysis leads toward the system functional and technical

requirements definition for the aeronautic applications, which are summarized in Table . Each requirement is described by its

• Code, alphanumerical expression that allows identifying the requirement. Each requirement 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

Valida-

tion (T/A/S)

Ele-

ment

Func-

tion

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


needed to estimate the hull

components health

T SE_1 F1

AeSR_3 UR_1 H


needed to estimate the door

T SE_1 F1

CHOSeN




Code User Req.

Priority (H/M/L)

Description Valida-tion

(T/A/S)

Ele-ment

Func-tion

surrounding

structure health

AeSR_4 UR_1 H

The acquired sensor data must be with

the specified accuracy &

resolution

T SE_1 F1

AeSR_5 UR_1 H

The acquired data

must be stored in non-fluid memory

in the wireless node

T/A SE_1 F1

AeSR_6 UR_1 H

The system must provide the

interfaces necessary to

connect the specified sensors

T/A SE_1 F1

AeSR_7 UR_2 H

The communication

system must support a reliable

data communication

T/S SE_2 F2

AeSR_8 UR_2 H

The communication system must

support

synchronized communication

T/S SE_2 F2

AeSR_9 UR_2 M

The communication system must

provide a redundant channel

T/A SE_2 F2

AeSR_10 UR_2 M

The communication

system must have an interface

towards the aircrafts wired

backbone

T/A SE_2 F2

CHOSeN




Code User Req.

Priority (H/M/L)


(T/A/S)

Ele-ment

Func-tion

AeSR_11 UR_2 H

The communication

system must be capable of

automatic setup/

initialization

T/S SE_2 F2

AeSR_12 UR_2

UR_4 H

The wireless

network must be able to add new

nodes

T/S SE_2 F2

AeSR_13 UR_2

UR_4 H

The wireless

network must be

able to delete nodes

T/S SE_2 F2

AeSR_14 UR_2 UR_4

H

The wireless network must

support the specified

communication modes (poll, event)

T/S SE_2 F2

AeSR_15 UR_2 H

The wireless nodes

components must be able to be

separately switched on/off

T/A SE_2 F2

AeSR_16 UR_2

UR_4 H

The communication

system must support

prioritization

T/S SE_2 F2

AeSR_17 UR_2 H

The communication

system must be able to detect and

communicate the energy source state

T/S SE_2 F2

AeSR_18 UR_2 M

The communication

system must support energy-

harvesting driven nodes

T/S SE_2 F2

CHOSeN




Code User Req.

Priority (H/M/L)


(T/A/S)

Ele-ment

Func-tion

AeSR_19 UR_2 M

The communication

system must be able to address

single nodes via the

WUR

T/A SE_2 F2

AeSR_20 UR_1 H

The system must

be able to process and fuse data

locally

T/S SE_3 F3

AeSR_21 UR_1 H

The system must

be able to process

and fuse data in the access points

T/S SE_3 F3

AeSR_22 UR_1 H

The system must be able to predict

the health state of the monitored

components

T/A SE_3 F3

AeSR_23 UR_3 H The system must be able to configure

the sensors

T/A SE_2 SE_4

F2-F4

AeSR_24 UR_3 H

The nodes must

store their configuration and

state

T/A SE_1

SE_4 F1..F4

AeSR_25 UR_3 H

The HMI must provide facilities to

configure the specified

parameters

T SE_4 F4

AeSR_26 UR_1 H

The system must store the specified

states, values and parameters in a

central database

T SE_4 F4

AeSR_27 UR_1 H The system must

display the T SE_4 F4

CHOSeN




Code User Req.

Priority (H/M/L)


(T/A/S)

Ele-ment

Func-tion

specified states,

values on a GUI

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