chosen project report - tu braunschweig · chosen deliverable d1.2b: requirements analysis document...
TRANSCRIPT
![Page 1: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/1.jpg)
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
![Page 2: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/2.jpg)
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
![Page 3: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/3.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 3
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
![Page 4: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/4.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 4
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
![Page 5: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/5.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 5
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
![Page 6: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/6.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 6
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.
![Page 7: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/7.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 7
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
![Page 8: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/8.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 8
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)
![Page 9: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/9.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 9
- 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
![Page 10: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/10.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 10
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
![Page 11: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/11.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 11
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.
![Page 12: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/12.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 12
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.
![Page 13: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/13.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 13
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.
![Page 14: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/14.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 14
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
![Page 15: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/15.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 15
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
![Page 16: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/16.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 16
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.
![Page 17: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/17.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 17
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.
![Page 18: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/18.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 18
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)
![Page 19: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/19.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 19
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
![Page 20: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/20.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 20
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
![Page 21: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/21.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 21
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
![Page 22: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/22.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 22
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
![Page 23: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/23.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 23
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.
![Page 24: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/24.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 24
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.
![Page 25: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/25.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 25
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).
![Page 26: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/26.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 26
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
![Page 27: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/27.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 27
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
F1 - Data Acquisition
F2 - Communication
F3 - System Monitoring
F4 - Human Machine Interface
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
![Page 28: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/28.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 28
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
F1 - Data Acquisition
F2 - Communication
F3 - System Monitoring
F4 - Human Machine Interface
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
![Page 29: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/29.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 29
• 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,
![Page 30: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/30.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 30
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
![Page 31: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/31.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 31
Functional Tree
F1 - Data Acquisition
F2 - Communication
F3 - System Monitoring
F4 - Human Machine Interface
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:
![Page 32: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/32.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 32
• F4.1 – Configuration
• F4.2 – Network state reporting
• F4.3 – Systems health state reporting
Functional Tree
F1 - Data Acquisition
F2 - Communication
F3 - System Monitoring
F4 - Human Machine Interface
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.
![Page 33: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/33.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 33
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
![Page 34: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/34.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 34
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
![Page 35: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/35.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 35
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
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
![Page 36: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/36.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 36
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
![Page 37: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/37.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 37
Code User Req.
Priority (H/M/L)
Description Valida-tion
(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
![Page 38: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/38.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 38
Code User Req.
Priority (H/M/L)
Description Valida-tion
(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
![Page 39: CHOSeN Project Report - TU Braunschweig · CHOSeN Deliverable D1.2b: Requirements analysis document for the aeronautic applications Copyright CHOSEN Consortium 2008-2011 Page 8 close](https://reader033.vdocument.in/reader033/viewer/2022060514/5f8321bd6a6de15c5d6de075/html5/thumbnails/39.jpg)
CHOSeN
Deliverable D1.2b: Requirements analysis document for the
aeronautic applications
Copyright CHOSEN Consortium 2008-2011 Page 39
Code User Req.
Priority (H/M/L)
Description Valida-tion
(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