Fucntional Specifications - CORDIS...parameterized UI. Only relevant alerts (e.g. retreat) can and must trigger his attention. A fire-fighter has more important actions to perform

IWT- Knowledge Centre Procurement of Innovation D3.1 Contact Smart@Fire: Project Manager Anne Van Snick ([email protected] ) version:1.0 Project Director Christophe Veys ([email protected]) page:1

Fucntional Specifications

mailto:[email protected]



Table of Contents Table of Contents ............................................................................................................................... 2

Acronyms and abbreviations .............................................................................................................. 3

Definitions .......................................................................................................................................... 3

1 Positioning the document ........................................................................................................... 4

1.1 Context .................................................................................................................................... 4

1.2 Objectives ................................................................................................................................ 5

1.3 Approach ................................................................................................................................. 5

2 Priority use-cases in scope of Smart@Fire PCP Tender .............................................................. 7

3 High-level functional requirements for the Smart@Fire PPS in scope of the PCP Tender ....... 10

4 Functional architecture of the Smart@Fire PPS in scope of the PCP Tender ........................... 13

4.1 Actors..................................................................................................................................... 15

4.2 Functional building blocks enabling key use-cases ............................................................... 16

4.3 Functional specifications of the functional building blocks .................................................. 18




Acronyms and abbreviations

Acronym/Abbreviation Description

PPS Personal Protective System

PPE Personal Protective Equipment

Definitions For the purpose of the project Personal Protective System (PPS) means: all parts of the equipment

worn by an individual fire fighter including auxiliary elements and that protect the individual from

hazards to his health and safety. All parts from head to toes and from skin to outer layer are

included. This includes (non-exhaustive list) : Personal Protective Equipment (PPE), non PPE clothing,

ICT hardware and software, data logging, monitoring sensors, warning systems, localization

equipment, … Accurate monitoring and warning for both the individual fire fighter and the incident

management are part of the PPS.




1 Positioning the document

1.1 Context To better protect firefighters and first responders from hazards to their health and safety, the

European project Smart@Fire (FP7-ICT-2011-8) envisions the next generation Smart Personal

Protective System (PPS): an integrated system covering primarily localization and positioning,

environmental sensing, body monitoring, data transfer and visualization for remote coordination, data

interpreting intelligence, intuitive audiovisual feedback, smart textiles, etc.

Although research for smart textiles and Smart PPS has already been conducted through numerous

research projects on local and European level, none of these programs have advanced to the state of

being able to present a working prototype that is ready for day-to-day use. While first technological

advancements are finally finding their way into this field, today, for fire and rescue operations there is

no complete system on the market

Smart@Fire starts from a concrete need for which the market at the moment cannot offer a suitable

solution and R&D efforts remains to be performed by suppliers. The situation is even more complex as

the procurers have no clear idea about functionality and required performance of the solution: at best,

fire brigades and first responders can describe the desired outcome or effect of the innovation, which

is a more general requirement than a functional ICT requirement. In this case the procurers cannot

enter into a regular procurement exercise, but have to spur the suppliers to enter into an R&D

development by launching a PCP.

Pre-commercial procurement aims primarily at reducing the risks inherent to R&D in order to avoid1:

procurers to purchase the development of technologies already available on the market, but

not responding to their real needs;

procurers to purchase R&D that is technically/technologically too challenging and unrealistic

to result in an industrial cost-effective application.

Taking these two points into account a phased approach is required in order to achieve the goals of a

PCP. The PCP phased approach covers following subsequent phases:

Preliminary phase: Needs assessment and state-of-the-art study to determine priority

innovative end-user requirements

First phase: Innovation Platform as market consultation instrument to identify the innovation

potential from technological perspective and sharpening the PPS prototype scope.

Second phase: Joint Pre-Commercial Procurement: the developments of prototypes,

organized in 3 stages: “solution exploration”, “prototype development”, and “production of

first batch”.

Third phase: Final Joint Procurement of Smart PPS

As initiating act of the second phase, the joint PCP tender documents are published. The PCP tender

will not specify/favor/exclude a technological solution but will mainly address the functional

1 Wilkinson report, “Public procurement for research and innovation: developing procurement practices favorable to

research and innovation”, 2005




requirements of the Smart@Fire prototype scope as defined in the final report of the innovation

platform. Throughout the innovation platform market consultation sessions, functional requirements

have been treated at building block level, with targeted in depth discussions on identified complexities,

issues. In addendum to the PCP tender documents, this document elaborates the functional

specifications of the PPS prototype.

Functional requirements situate at multiple levels of detail:

High-level user requirements are the priority use-cases identified via user needs assessment.

To enable these use-cases, a functional reference architecture is formed, explaining the overall PPS system and main functional building blocks.

For each functional building block, multiple sources of risk/complexity have been identified. These aspects are again translated as more detailed functional requirements.

…

<all features and specifications>

…

A detailed datasheet of the complete system and all of its SW/HW modules and all performance related parameters

During the Solution Exploration phases and Prototyping stages, these functional requirements will

be validated further with the end-users and evolve to more and more detailed datasheets.

1.2 Objectives The objective is to create a ‘PPS prototype functional specification’ file defining functions, information

flows (inputs, outputs, interactions), modules, interfaces, integration aspects etc. elaborating upon the

reference architecture with functional building blocks and keeping closely in mind the priority user

needs that need to be fulfilled through the functional building blocks/requirements.

The functional specifications do not define the inner workings of the proposed system, do not include

the specification of how the system functions will be implemented and do not prescribe which

technological choices to make. Instead, focus is put on what various outside agents (people using the

program, computer peripherals, or other computers, for example) observe when interacting with the

system.

1.3 Approach An iterative approach is adopted where each iteration delivers the functional requirements elaborated

to a more detailed level. Each iteration follows a logical stepped approach. The first iteration’s logical

frame comprises:

1. Start from priority use-cases enabled by the PPS prototype scope as concluded upon in the

final report of the innovation platform. Take into account the user’s context and reasoning

behind the selection as priority.

2. List impacted actors and their roles and responsibilities.

3. Translate these use-cases into task descriptions, actions, interfaces with the system underlying

building blocks or functional modules.

4. For each building block or functional module, translate actions and interfaces into functional

specifications, that directly relate to the users’ tasks and interactions with the system.




1.4 Document structure Following sections comprise a stepped approach towards the formulation of the functional

requirements, by answering in each section & key question:

Section 2: which priority use-cases (as indicated by the firefighters themselves) are to be realized by

the Smart@Fire PPS prototype?

Section 3: which high-level functional requirements form the basis of the Smart@Fire PPS prototype

solution design?

Section 4: which functional building blocks constitute the Smart@Fire prototype functional

architecture, given the priority use-cases to enable?

Section 4.1: which key-actors are involved in the functional use of the Smart@Fire prototype?

Section 4.2: for each use-case, which functional building blocks are needed?

Section 4.3: for each of these functional building blocks, which functional requirements are

identified to take into account during prototype solution design and development?




2 Priority use-cases in scope of Smart@Fire PCP Tender

The table hereafter describes for each use-case the reasoning of the end-users behind the selection

as priority.




Nr User context of WOW! <BE> User context of WOW! <FR> User context of WOW! <UK>

25 Extremely useful to coordinate the team and to locate injured or unresponsive team members. The toughest challenge will be to transmit position information as building often act as Faraday’s cages.

This use-case holds major added value: location is crucial.

This use-case holds major added value: location is crucial.

28 In sequence of importance: the most important thing to know by far is each team member’s position. Second is the temperature in the environment and third, the status of his/her PPE. To monitor these things from a distance, transmission of data is the toughest challenge.

This is core information for the coordinating officer.


29 The ICO is responsible for his/her team’s safety. To be able to warn his team is a clear advantage. Solutions used today (e.g Tetra) often suffer from connection problems.

Radio communication, tetra-based solutions, etc. exist but typically only work unidirectional from fire-fighter to central dispatch, within limited distance range, and in case the signal doesn’t get distorted across concrete walls. Being able to provide feedback would mean a significant plus to the intervention coordination officer.

In theory, UK fire brigades today have the functionality to communicate with their team, however it doesn’t always work. The scope of this use-case should be extended towards sector-wide, zone-based and team-based alarm generation, which is not existing today.

30 Trivial advantage For the intervention coordinating officer to work effectively, the abundance of available info on fire-fighters, equipment and environment must be presented in an intuitive fashion, filtering out all non-relevant parameters.

For the intervention coordinating officer to work effectively, the abundance of available info on fire-fighters, equipment and environment must be presented in an intuitive fashion, filtering out all non-relevant parameters.

31 Generating automatic alarms would already be a great advantage to help an ICO set his focus. More far-going automation seems unrealistic as such large quantities of different parameters need to be filtered and interpreted.

Additionally to the intuitive presentation of the information, semi-automated interpretation can have major impact on the coordinating officer effectiveness of way of working. Important note is that final decision making remains responsibility of the officer, not the automated interpretation engine.

Additionally to the intuitive presentation of the information, semi-automated interpretation can have major impact on the coordinating officer effectiveness of way of working.

32 Due to the harsh conditions firefighters work in, clear visualization is often a problem.

A fire-fighter has more important actions to perform during a fire encounter, than watching a parameterized UI. Only relevant alerts (e.g. retreat) can and must trigger his attention.

A fire-fighter has more important actions to perform during a fire encounter, than watching a parameterized UI. An intuitive UI displaying only relevant alerts (e.g. exception reporting) is required to realize the significant added value.




36 Today, such equipment is not available or not adequate. It would lead to more efficient and effective training.

Training real-life situations is key for safety assurance of fire-fighters during fire encounters.

Training real-life situations is key for safety assurance of fire-fighters during fire encounters.

38 Today such system does not exist, but would lead to better decisions and allow root cause analyses. Note, such information can be used to research practical thresholds.

This use-case represents an unaddressed need today. The analysis of the historical logging is not necessarily performed by the department head, but is of major importance for improving safety policies.

The analysis of the historical logging is not necessarily performed by the department head, but is of major importance for improving safety policies.

40 For tracking purposes; to show all necessary actions have been conducted, this is extremely valuable for a department head.

Similar to UC38 This way the department head can always explain the good intentions of the teams, confirm that all rules have been applied, etc.

44 Such functionality does not exist today and would lead to better safety.

This would be great, but seems too good to be true.

Major added value, given 'rely on' holds full trust in the self-assessment.

45 Functionality has value as the firefighter himself can check the status of his PPE making him less dependent of the PPE manager’s decision. This will make it very unlikely that bad quality PPE’s are used during interventions.

Today, equipment assessment is carried out by dedicated control personnel, not the fire-fighters themselves. Main reason is that this control requires certain expertise, which is not shared across all fire-fighters. By providing an easy-to-operate self-assessment, fire-fighters can be asked for more responsibility regarding their own equipment, under the precondition they receive proper training.

Today, equipment assessment is carried out by dedicated control personnel, not the fire-fighters themselves. Main reason is that this control requires certain expertise, which is not shared across all fire-fighters. By providing an easy-to-operate self-assessment, fire-fighters can be asked for more responsibility regarding their own equipment, under the precondition they receive proper training in order to avoid that the self-assessment itself will carry responsibility.

47 Trivial advantage Easy operations and maintenance is a trivial, but major added value.

Easy, user-friendly operations and maintenance is a trivial, but major added value.

48 Trivial advantage Easy operations and maintenance is a trivial, but major added value.

Easy operations and maintenance is a trivial, but major added value.

26 The officer can act as a guardian angel. Firefighter can do their job while somebody outside monitors their health status and position. In case thresholds are crossed, alerts can be send out.



27 Similar to UC26 Similar to UC26 Similar to UC26




7 Alternative measurement via the handheld IR camera, but not all FF are equiped with these and screen is difficultly read due t gasses, smoke.

In a non-urban situation environmental temperature measurement can give an indication about direction and velocity of the fire expansion.

While the environment is a primary parameter to assess the situation and assure own integrity, fire-fighters do not sense it anymore due to their heat resistant textiles. And not all fire-fighters understand the limitations of their gear.

9 Similar to UC7 Similar to UC7 Similar to UC7

16 Gas detectors are already in use, but usually only one person uses it and therefore, the whole team depends on it. For safety reasons (imagine wind changes) and better decision making, it would be of value to equip all firefighters with such a gas detector. Also: today these meters are heavy and would imply another thing to carry along, on top of the gear they are carrying already. Therefore, a lightweight, integrated solution would be well appreciated.

For this vital functionality dedicated equipment exists, but is not integrated in the PPE. As a result this equipment is often forgotten. Solving this by integration in the PPE generates other constraints, such as incapability of performing specifically localized measurements (in floor or ceiling), limited range of measurement (just around the body).

For this vital functionality dedicated equipment exists, but is not integrated in the PPE. Measuring explosive gasses is not performed in the direct environment of every fire-fighter at the scene. Integration in the PPE can solve this.

3 High-level functional requirements for the Smart@Fire PPS

in scope of the PCP Tender Throughout the market consultation sessions during the innovation platform, following high-level

functional requirements have been captured:

Configuration of the PPS system: different types of interventions require different

functionalities (e.g. in a forest fire a lighter helmet and turnout gear is chosen/required), the

system architecture should allow for flexible operation and configuration. 4 main

configurations can be distinguished:

o Basic configuration: localization + remote connectivity + intuitive visualization

o Physio configuration: localization + remote connectivity + intuitive visualization +

physiological monitoring

o Urban configuration: localization + remote connectivity + intuitive visualization +

environmental monitoring

o Full functional configuration: localization + remote connectivity + intuitive

visualization + physiological monitoring + environmental monitoring

Autonomy: given that different types of interventions require different types of PPE according

to norms (forest fire vs. urban fire in confined areas), a different set of functionalities is

required (e.g. in forest fire no toxic gas detection or IR camera sight is required, only

localization and communication suffice), and span different durations. A typical intervention

in an urban setting with breathing apparatus takes 20 to 40min, depending on the intensity of

the intervention in relation to the air volume in the bottle. In a forest fire situation,




intervention times of up to 3 hours are noted in case of no excessive efforts, 1 to 2 hours in

case of running. So in summary, the minimally required autonomy for the PPS system is about

2 hours when all functionalities are operational, and up to 4 hours in a forest fire configuration.

Weight: Current firefighter turnout gear weight amounts around 25 to 30kg of which 3 to 4kg

is due to turnout gear garment. The remaining weight covers boots, helmet, breathing

apparatus, handheld illumination, water hose, etc. As a consequence the Smart@Fire PPS

prototype should be kept as lightweight as possible striving to maximally add 1-2 kg, well

balanced around the body. This includes battery weight.

Speed of deployment: today’s procedures aim to minimize the delay between the first alert

arriving at the dispatch center and the arrival onsite. Typically during daytime (and in the case

of an online brigade), firefighters are given 3 minutes to get in the turnout gear, receive short

intervention briefing on location and situation, and gather in the truck. (At night time this is 5

minutes). The breathing apparatus, water hoses, etc. are kept in the truck. They remain fixed

during transit, resisting shocks up to 10g. The aim is to arrive on site within 5 to 10 minutes,

so the time to launch the PPS ICT system and reach the operational state is of the same order

of magnitude (~10 minutes).

Refresh rate of data transfer from the deployed firefighters in the field towards the remote

intervention coordinating officer/command center is ideally performed in near real-time

(~1Hz). This is considered sufficient to keep track of the firefighters’ movements as firefighters

in the field move at limited walking speed.

Accuracy of the localization system: in open areas an accuracy of localization of about 3 to 4

meters is sufficient. In confined areas, a higher accuracy is requested up to 1m. In confined

areas the aim is to find a victim, make a correct assessment whether a person is on one side

of the wall or the other, etc. In case inertial or alike localization technologies are used,

measurements should be updated at least at a 10cm interval or less.

Standard interfaces between wirelessly connected devices on the firefighter: in case for

example a firefighter is equipped with wirelessly connected environmental sensing devices

(e.g. temperature, explosive gas detection), the communication protocol applied should be a

known standard (preferably Bluetooth) with known application profile and managed duty

cycles for extended autonomy.

Fraud proof: Fraud-proof inherently refers to measures against jamming and spoofing.

Jamming refers to intentionally electromagnetically interfering with the system to make it

unavailable. Spoofing is more advanced in the sense that the system is interfered by falsifying

data without the system detecting it. Today, relatively cheap but narrowband jammers are on

the market for around 40$. To jam on a broader spectrum requires significant emission power.

Concerning making the system fraud-proof, the risk depends on how far measures are pushed.

For fire and rescue applications, fraud countering measures should be implemented taking the

assumption of normal civil environments. Military-grade measures are considered out of scope

for this project.

Lifecycle: today the average lifecycle of PPE turnout gears is ca. 8 years (with variation

between 2 to 14 years (depending on the intensiveness of use, potential incidents during

interventions, etc.). The lifecycle of the additional supplementary ICT components in the PPS

should ideally corresponds to the lifecycle of the PPE turnout gear (same order of magnitude

of around 5 to 8 years). (Standalone components of the PPS (e.g. components which can be




easily removed from the turnout gear and hence are not subjected to aggressive cleaning

procedures) could possess a shorter lifecycle of e.g. 2 to- 3 years).

Robustness under washing and exposure to specific substances (in case the PPS holds

functional building blocks which are exposed to the hazardous environment)

o washing procedures: <details of washing procedure and expected results>

o exposure to chemicals, toxic gasses, etc.: <details of test procedure and expected

results>

Performance under test scenarios of the prototype:

Test scenarios are envisaged on 4 levels:

1. Standardization tests of the PPS turnout gear, according to the prescribed testing

procedures for a PPE class 2 in EN469:2005.

2. Standardization tests of the PPS ICT components considered as standalone devices

according to known directives and harmonized standards decoupled from the turnout gear

(IEC Ex, IP6X, etc.)

3. Recommended testing in line with the recommended PPS conformity assessment

procedure (as described in the Tender Documents – Design Contraints). In addition to the

known distinct standards and directives for PPE and for ICT related firefighting products

and solutions, it is recommended that the conformity assessment procedure of the

Smart@Fire PPS prototype and first batch of products describes a selected set of testing

procedures to be performed with the PPS prototype/product as a whole (i.e. PPE turnout

gear on manikin equipped with the supplementary ICT technological subsystems). The

additional tests can directly be derived from the most common standard tests used on fire

fighter suits (as defined in EN469). Structured from relatively easy to fulfill towards more

challenging, the Smart@Fire PPS as a system should be subjected to following system

tests:

Heat resistance ISO 17493 5min at 180°C No melting, no dripping, no ignition, remain functional, able to remove Radiant heat EN ISO 6942 40kW/m²

Convection heat EN 367 80kW/m²

Flame engulfment SCBA EN 137 …

In addition to these tests, 2 additional lab tests are recommended: the rain tower test, and

sweating manikin test.

At least the results of these tests should be known to the user community given the

potential impact on health and safety. As such this is part of the pre-commercial

procurement tender. Tenants will be asked to clarify their view on the conformity

assessment procedure of the PPS prototypes and first batch of products and will be

qualified on the test results as described in the functional specifications and awarding

criteria.

4. Functional field tests: a comparative study will be organized between selected suppliers.

These tests will not be performed in a controlled lab environment. Throughout these tests

consultation between a jury, test persons, suppliers (e.g. by presenting certain info to the

jury and test persons) and potentially external experts is allowed.

The jury is composed out of a number of Belgian and French firefighters and

intervention coordinating officers, who are identified by the public procurers

based on their expertise, experience and neutrality. The public procurers chair the




jury. Additional internal specialists (legal, administrative, technical) can be

assigned a seat in the jury.

The test persons are 6 to 8 firefighters and intervention coordinating officers from

the public procurers, who are selected based on their experience and expertise in

the field. Several firefighters will also have experience as instructor.

External experts are assigned based on their specific expertise (medical,

innovation, technical,…) by the public procurers to provide their objective advice

to the jury.

Note: only the jury will award final testing points, but always taking into account the

test results as obtained by the lab, test persons, experts,…

Throughout the subsequent phases of the pre-commercial procurement procedure

(solution exploration, prototyping, and production and testing of final batch) more

details on the testing procedure will be shared with suppliers.

4 Functional architecture of the Smart@Fire PPS in scope of

the PCP Tender Given the priority use-cases in scope of the Smart@Fire PPS prototype, the PPS reference architecture

is formed by 26 abstract PPS building blocks, logically grouped in functional areas:

S Location/positioning systems: e.g. my location, that of my team members…

S Environmental sensors: e.g. temperature outside PPE, presence of toxic gasses…

S Body sensors: e.g. my heart rate, hydration level…

S PPS sensors: e.g. integrity, sweat…

I Intelligence: e.g. interface capability to launch alerts…

R Relay (Remote monitoring): e.g. availability of firefighters’ data for external team members…

G Integration: integration of capabilities without exceeding weight or available power supply…

The functional architecture and 26 functional modules are depicted below and listed in the table

hereafter. The modules listed in gray are only part of the PPS prototype through interfacing with

another standalone subsystem (e.g. temperature sensing module, explosive gas detection module,

physiological monitoring module):




Area Code Name Note

Intelligence I1 Audio/image/haptic belt

Intelligence I2 Control Intelligence I3 Intelligent data proc.

(thresholds alerts)

Intelligence I4 Int. PPE integrity, alerts

Intelligence I5 Logging

Integration G1 Integration: ICT > Textile

Integration G2 Energy supply

Position S2 Colleagues

Position S3 Forrest

Position S4 Building

Environment S7 Explosive Standard interface

Environment S8 Temp. Standard interface

Body S10 Body temp Standard interface

Body S11 Body HR Standard interface

Body S12 Body H20 Standard interface

PPE S15 PPS self-assessment

Relay R1 Visualization

Relay R2 Logging Position Relay R3 Logging Environment Basic parameters

Relay R4 Logging Health Basic parameters

Relay R5 Logging PPE




Relay R6 Intelligence (Monitoring)

Relay R7 Escalate

Relay R8 Aggregation

Relay R9 Alerts

Relay R10 Communication

In section 4.3, the functions of the functional building blocks will be reflected on in detail.

4.1 Actors The primary impacted actors by the priority use-cases who rely on the functional architecture building

blocks are described in the table below:

Actor Ability

Actor 1 Firefighter Responsible for:

performing fire & rescue, technical or civil protection interventions, fully exposed to hazardous conditions

protecting, safeguarding citizens in emergency situations

protecting firefighter partner(s) in own deployed team and other teams

Actor 2 Intervention Coordinating Officer

Role exists at multiple aggregation levels and can be assisted by an intervention safety officer at higher level of command and coordination. The safety officer is responsible for deploying the search and rescue firefighter team. Responsible for:

coordinating interventions following strictly applied operational and tactical procedures

coordinating the activities of multiple deployed firefighter teams (of 2 or 3 teams of 2 or 3 firefighters), including deployment, providing directions, alerts, alarms, retreat commands, etc.

Actor 3 PPS Manager Person or group of persons (including the firefighters themselves) responsible for:

regularly checking PPS equipment following strictly applied maintenance procedures, to validate functionality

performing, managing, verifying cleaning operations

performing, managing, verifying repair operations

Actor 4 Trainer Responsible for:

providing training scenarios and measuring performance levels of the professional and volunteering firefighters on a regular basis

Actor 5 Department Head

Responsible for:

Setting the fire and rescue and civil protection policies in line with applicable legislation and to be translated in operational and tactical procedures

Ordering audit trails for intervention debriefings




4.2 Functional building blocks enable key use-cases The functional building blocks of the reference architecture as listed in section 4 above enable (1) or

contribute (0,5) to the realization of the key use-cases, as presented in the table below.







4.3 Functional specifications of the functional building blocks The functional architecture is further detailed below: for each functional building block, the main

functional specifications as identified today are listed.







In the table below, for each functional building blocks the functional specifications are elaborated.

These functional specs should be taken into consideration on top of the high-level functional

requirements described in section 3.

Functional building block

Function Functional Specifications

Localization, position system S2 – Colleagues S3 – Forest S4 - Building

Self-calibrate, self-reference, time synchronize

Once deployed the localization devices shall become operational seamlessly.

Measure absolute (outdoor) position data

The localization system shall measure the outdoor Cartesian coordinated position (X,Y,Z) using a professional GPS receiver with some electromagnetic shielding applied to limit signal degradation by interference. Outdoor localization accuracy shall be at least 3-4m Circular Error Probable (CEP), obtained by applying a professional Differential GPS receiver. The measurement accuracy shall be at least 10cm (1 measurement every 10cm), the measurement frequency depends on the velocity.

Measure relative (indoor) position data

The localization system shall measure the indoor relative position (x,y,z) with respect to an absolute reference position, i.e. the last known absolute position. Accuracy in this context relates to the determination of the relative position within the reference coordinate system set-up at system launch. Indoor localization accuracy shall be at least 1m Circular Error Probable (CEP), to localize colleague firefighters at the scene at the right side of a wall. The measurement accuracy shall be at least 10cm (1 measurement every 10cm), as a consequence required measurement frequency depends on the velocity.

Estimate absolute localization accuracy as confidence metric

The localization system shall include a localization confidence metric taking into account the elapsed time of last update of absolute position, the accuracy of that measurement, and the estimated error on relative indoor positioning,…

Generate trigger when absolute localization is not available

The localization system shall include an internal flag to indicate absolute reference position signals are not reachable.

Measure additional info:

The localization system shall measure the relative orientation (α) with respect to an absolute reference, e.g.




orientation, body posture, etc.

electromagnetic north or position of intervention coordinating officer; the body posture in e.g. 3 poses: straight-up, kneel/bow, down

Measure relative distance between team members and teams

(Optional) The localization system incorporates a mechanism to scan the neighborhood for colleague firefighters, with accuracy of ~1m CEP. A less risk bearing method is to determine distances between deployed team members and teams via relay over the intervention coordinating officer.

Output location data

The output data shall contain: - absolute 3D position and 2D orientation - measurement confidence metric - relative distance towards other team members (if

locally determined) - any additional measured parameters body posture,

etc. The output mode of operation shall be either broadcast (push, with optimized/synchronized duty cycles) or on request (pull).

Physiological monitoring S10 – Body Temperature; S11 – Heart rate S12 – dehydration level

Measure physiological parameters

Physiological monitoring primarily involves measuring skin temperature, estimating body core temperature, measuring heart rate and estimating dehydration level (by monitoring temperature and humidity). This function is out of scope of the PPS prototype, as the PPS prototype will not develop a new physiological monitoring system, but merely interface with it via a standardized interface.

Output physiological monitoring parameters

The standalone 3rd party physiological monitoring system should output the physiological monitoring data via standardized interfacing protocol with known application profile (wireless e.g. Bluetooth). The output data should include following parameters: T skin, T body core, T body core accuracy, heart rate, dehydration level, dehydration level accuracy, and potentially heat stress or skin burn alarm probabilities or flags (in case local processing of capture data within sensor device). Update rate should be near real-time, ideally through synchronized communication with optimized duty cycles.




Environmental temperature S8

Measure environmental temperature

This function is out of scope of the PPS prototype, as the PPS prototype will not develop a new environmental temperature sensor, but merely interface with it via a standardized interface.

Output environmental temperature

The standalone 3rd party environmental temperature sensor should output the environmental temperature via standardized interfacing protocol with known application profile (wireless e.g. Bluetooth). The output data should simply include the environmental temperature. Update rate should be near real-time, ideally through synchronized communication with optimized duty cycles.

Environmental monitoring S9 – explosive gasses

Measure environmental explosive gasses

This function is out of scope of the PPS prototype, as the PPS prototype will not develop a new environmental explosive gas detector, but merely interface with it via a standardized interface, under the precondition that a qualitative cost-efficient gas detector is identified, as all deployed firefighters should ideally be equipped with such a device.

Output environmental explosive gasses

The standalone 3rd party environmental explosive gas detector should output a flag whether explosive gasses have been detected via standardized interfacing protocol with known application profile (wireless e.g. Bluetooth). Update rate should be near real-time, ideally through synchronized communication with optimized duty cycles.

PPS Self-assessment S15 and PPS safety assessment intelligence I4

Run self-diagnostics

Upon demand of the user, the PPS shall be capable of running self-diagnostics to simulate, verify correct functioning of all functional modules.

Download self-diagnostics data and report

The user shall be capable of downloading from the PPS the last self-diagnostics data and transform it into a report

Input last full check-up timing

The user shall be capable of inputting the date and time of last full check-up and store it in the PPS.

Generate maintenance (re-calibration) or repair alerts

The PPS shall be capable of generating maintenance or repair alerts, based on e.g. time since last maintenance check-up, time used in interventions, time used in extreme conditions, or even background diagnostics checks, etc.

Generate power low alerts

The PPS shall be capable of flagging low power alert.




Provide basic maintenance instructions

The PPS shall provide the PPS Manager with instructions on basic maintenance procedure to be carried out by the PPS Manager, in line with inspection procedures on breathing apparatus. The inspection procedure shall minimally include easy identification of the PPS (e.g. barcode scanning), an event log with few key dimensions to fill in. This procedure should describe the general inspection methods, but should leave some flexibility w.r.t. performing these tests (as different brigades may use different inspection approaches).

Include yearly in-depth check-up service

The PPS as a complete solution shall include a servicing component either offered through inspect/repair/replace services or via training and certification programs to do it yourself as PPS Manager.

Sensor interface I-6

Capture localization parameters

The sensor interface shall include a data capture mechanism interfacing with the localization and positioning system via standardized interfacing protocol with known application profile (in case localization system and local processing device are separate HW devices with wireless or wired interconnection).

Capture physiological monitoring parameters

The sensor interface shall include a data capture mechanism interfacing with a standalone 3rd party physiological monitoring system via standardized interfacing protocol with known application profile (wireless e.g. Bluetooth). The exchanged data should include following parameters: T skin, T body core, T body core accuracy, heart rate, dehydration level, dehydration level accuracy, and potentially heat stress or skin burn alarm probabilities or flags. Update rate should be near real-time, ideally through synchronized communication with optimized duty cycles.

Capture environmental temperature measurements

The sensor interface shall include a data capture mechanism interfacing with a standalone 3rd party environmental temperature measurement system via standardized interfacing protocol with known application profile (wireless e.g. Bluetooth). The exchanged data simply consists of environmental temperature. Update rate should be near real-time, ideally through synchronized communication with optimized duty cycles.

Capture environmental explosive gasses detection

The sensor interface shall include a data capture mechanism interfacing with a standalone 3rd party environmental explosive gas detector via standardized interfacing protocol with known application profile (wireless e.g. Bluetooth).




The exchanged data simply consists of environmental explosive gas detection flag. Update rate should be near real-time, ideally through synchronized communication with optimized duty cycles.

Capture generic data

For modularity and future-proof reasons, the sensor interface shall include one or more data capture mechanisms capable of interfacing with a standalone device via standardized interfacing protocol with known application profile (wireless e.g. Bluetooth). The exchanged data simply consists of a number of generic data fields of certain format.

Request new sensor data

The sensor interface shall be capable of requesting (polling) the connected sensor devices for updated measurement data.

Auto discover known sensor devices

The sensor interface shall be capable of discover newly plugged or wireless nearby new known sensor devices.

Generate lost connection alert

The sensor interface shall be capable of generating an alert in its communication with the local central processing unit, whenever the connection with one of its interconnected sensor devices (cabled or wireless) is lost.

Intelligent data processing I-3 (incl. thresholds, alerts

Automatically configure trade-off local vs. remote data processing

The local processing unit shall be capable of assessing whether it should process and interpret captured data locally, or wait for remote instructions and commands.

Take-in/request available sensor data and flags/alerts

The local data processing unit shall be capable of requesting the sensor interface for the most recently available sensor data

Update position data using hypotheses

The local data processing unit shall apply simple rule-based reasoning to filter out non-physical position jumps.

Track individual firefighters

The local data processing shall add the ID of the firefighter to the position data to enable individual named firefighter tracking.

Generate local navigation map

The local data processing shall include a relative ‘track & trace’ map concept.

Generate navigation instructions

The local data processing shall be capable of generating navigation instructions to enable ‘meet point’ and ‘recovery path’ applications on the relative map.

Generate local alerts

The local data processing unit shall include an alert generation mechanism to e.g. generate an ‘explosive gas detected’ alert, ‘heat-stress or skin burn’ alert, ‘flash-over’ danger alert, etc.




Store data - Update local data log

The local processing unit shall be capable of pushing all captured data, all data on activities, decisions, events, etc. to the local data log, enriched with firefighter id, timestamp, etc.

Preprocessing data for local storage

The local processing unit shall aim at efficiently storing the captured data, and hence may apply data preprocessing functions.

Retrieve data from local data log

The local processing unit shall be capable of operating on the local data store and extracting particular types of data, either for internal calculations, either for transfer to the communication module for relay towards the intervention coordinating officer.

Take-in received data from the communication module

The local data processing unit shall include a function to take-in received data from the communication module.

Interpret received data messages through the communication module

The local data processing unit shall include a data message interpretation function that transfers the received data in commands for logging, provide feedback, generate alerts, etc.

Receive communication related alerts

The local data processing unit shall be capable of receiving and interpreting communication related alerts.

Receive power related alerts

The local data processing unit shall be capable of receiving and interpreting power related alerts.

Data log I5 Store data locally The local data log shall be used to support all functions. It shall contains details of any data captured, any decision that has been taken, all actions that have been taken, events that have occurred, etc.

Manage data log read/write operations

The data log module shall be capable of securing conflictless data log read and write operations.

Manage storage memory overflow

If necessary, the data log module shall be capable of managing storage memory by using techniques as data compression (archiving), deleting older, centrally backed-up data,…




Intuitive user feedback system for the Firefighter I1

Provide multimodal feedback

The user-feedback system shall be multimodal, complementing following modalities: audio (e.g. computer voice generated messages), simple/basic UI (e.g. lights, buttons) and haptic belt. At all times ergonomic use should be safeguarded. Ideally, the audio feedback modality is integrated with the tactical radio device of the Firefighter.

Select modality automatically

The user-feedback system shall incorporate an automated modality selection mechanism, to predict an intuitive combination of modalities or to switch between modalities.

Provide minimal info/feedback

The user-feedback system shall provide minimal information to the firefighter to be aware of his situation, but without distracting during interventions. The user-feedback system shall provide a subset of following (non-exhaustive) information to the firefighter at the right time: system on/off (sub-)system error info: target position reached ("meet point") alarm: temperature/flash over, get out alarm: explosive gasses, get out alarm: heat stress/skin burn, get out info: get out recovery path instructions info: nearby colleagues detected alert: nearby colleague down info: lost connection to rest of team info: low power etc.

Control system for the Firefighter during interventions – I2

Simple switch-on, switch-off

The control system shall enable simple switch-on, switch-off the whole system by the Firefighters themselves (regardless of integrated cabling, wireless interconnections between multiple devices).

Other simple controls

The control system may incorporate few additional control functions, in line with existing approaches such as ‘push-to-talk button’, ‘panic button’.

Capture user inputs

The control system shall capture user input and translate into system commands.




Firefighter communication relay – R10

Determine trade-off message size vs. available bandwidth

Depending on signal strength, emission power, etc. the firefighter’s communication module shall be capable of determining the transmittable/receivable length of data messages.

Determine priority data types to transmit

The communication module shall be capable of selecting for each communication moment the priority data sources (e.g. location coordinates) to transmit to the intervention coordinating officer, given the available bandwidth, the situation at hand, any data requests received.

Extract data from local data log

The communication module shall be capable of extracting the right data from the local data log.

Preprocess data for transmission efficiency

Given the multitude on sensors and functional devices within the firefighter’s PPS, preprocessing of this data and structuring into an efficient data transfer format shall be incorporated as a function of the firefighter’s communication module (e.g. via command look-up tables).

Transmit data The communication module shall be capable of transmitting the preprocessed data, either in broadcast mode, either in an on-demand mode.

Route incoming messages

Throughout the communication architecture, each firefighter’s communication module acts as a node/switch or relay capable of routing incoming messages to the final destination(s).

Receive and unfold data messages

The communication module shall be capable of receiving and unfolding preprocessed data messages.

Make received data available for interpretation

The communication module shall be capable of pushing the received data to the local processing unit or alternatively making the received data available for interpretation capture by the local processing unit.

Generate alert ‘low signal strength, lost signal’

The communication module shall be capable of flagging ‘low signal strength’, ‘lost signal’ alerts.




Intervention Coordinating Officer communication relay – R10

Determine trade-off message size vs. available bandwidth

Depending on signal strengths, emission power, etc. the intervention coordinating officer’s communication module shall be capable of determining the transmittable/receivable length of data messages.

Determine priority data types to receive

The communication module shall be capable of requesting certain data types to the complete network or to individually deployed firefighters.

Request priority data

The communication module shall be capable of requesting certain data types to the complete network or to individually deployed firefighters.

Receive and unfold data messages

The communication module shall be capable of receiving and unfolding preprocessed data messages.

Preprocess data for transmission efficiency

Preprocessing data and structuring into an efficient data transfer format shall be incorporated as a function of the communication module (e.g. via command look-up tables).

Transmit data The communication module shall be capable of transmitting the preprocessed data, either in broadcast mode, either in an on-demand mode.

Determine network update frequency

Taking into account the current network performance in terms of available data rate, signal strengths, etc. the communication module of the intervention coordinating officer shall be able to determine the optimal update frequency (and communicates this to the different deployed firefighters). Alternatively, the update frequency can also be manually determined by the intervention coordinating officer. In this case the communication module should be capable of setting and communicating this target update frequency.

Generate alert ‘low signal strength, lost signal’

The communication module shall be capable of flagging ‘low signal strength’, ‘lost signal’ alerts.

Intuitive visualization for the intervention coordinating officer – R1

Display The visualization system shall consist of a display as primary feedback modality (e.g. ruggedized laptop, tablet computer, etc.) to remain as operational as possible when relocating in the intervention area.

Set hierarchical officer level

The visualization system shall be capable of visualizing the intervention situation at multiple hierarchical levels, depending on the role of the intervention coordinating officer during the intervention.

Set target network update frequency

The visualization system shall be capable of setting the required/desired network/data update frequency.




Import Cartesian coordinated map

In case a Cartesian coordinated map is available (e.g. Google maps satellite view of the area), the intervention coordinating officer shall be capable of importing this map and shall use it as overlay on the intervention coordinator’s intuitive map for better situational awareness.

Visualize intervention situation

The visualization system shall be capable of a number of capabilities, in line with intervention coordination procedures and decision/action triggers of the intervention coordinating officers who operate at multiple hierarchical levels (non-exhaustive list):

- Displaying relative 2D/3D track & trace map - Tracking of individual firefighters - Displaying their status, depending on which

measurement devices the firefighter at hand is equipped with (e.g. physiological parameters, environmental parameters, etc.)

- Displaying the accuracy of their location - Displaying their signal strength - Displaying any received alerts - Displaying any transmitted messages - Recommended alerts (automatically generated)

Action module to send alerts, messages,…

The visualization system shall include an action module from where the intervention coordinating officers can launch actions, messages, alerts towards the deployed firefighters or intervention coordinating officers operating at a lower level.

Action module to send navigation instructions

The visualization system shall include an action module from where the intervention coordinating officers can launch navigation instructions towards the deployed firefighters (or intervention coordinating officers operating at a lower level).

Additional data configuration function

In case additional data sources have been coupled locally (see also function ‘generic data capture’), the visualization system shall include a configuration module to allow interpretation of these data sources into meaningful info and related thresholds might be set accordingly.

Provide module to escalate alerts

The visualization system shall include a module from where generated alert escalation can be configured (e.g. automatic/manual escalation to identified higher levels of hierarchical coordination) and actual escalations can be performed.

Provide module to accept/refuse, configure aggregated intervention data

The visualization system shall include a module to configure data aggregation settings, to accept/refuse/automate aggregation of intervention data.




Central terminal processing unit – R6

Automatically configure initial trade-off local vs. remote data processing

The central processing unit shall be capable of determining the initial configuration of local vs. central data processing.

Push local vs. remote data processing configuration

The central processing unit shall initiate communication of the configuration to the deployed local firefighters.

Capture and interpret aggregated data

The central processing unit shall be capable of integrating captured aggregated data from other intervention coordinating officer.

Generate automatic alert recommendations

The central data processing unit shall include an alert generation mechanism to e.g. generate an ‘explosive gas detected’ alert, ‘heat-stress or skin burn’ alert, ‘flash-over’ danger alert, time-in-intervention alert etc. and translate these triggers in recommended alerts for the intervention coordinating officer to decide upon.

Update position data using hypotheses

The central data processing unit shall apply simple rule-based reasoning to filter out non-physical position jumps from individual firefighters and between firefighters.

Track individual firefighters

The central data processing will keep the ID of the firefighter linked to the received position data

Generate overall navigation map

The central data processing shall build and keep up-to-date a relative ‘track & trace’ map of the known intervention situation.

Generate individual navigation instructions

The central data processing shall be capable of generating navigation instructions to enable ‘meet point’ and ‘recovery path’ applications for individual firefighters on the relative map.

Store data - Update central data log

The central processing unit is capable of pushing all captured data, all data on activities, decisions, events, etc. to the central data log, enriched with firefighter id, timestamp, etc.

Preprocessing data for central storage

The central processing unit aims at efficiently storing the captured data, and hence may apply data preprocessing functions.

Retrieve data from central data log

The central processing unit is capable of operating on the central data store and extracting particular types of data, either for internal calculations, either for transfer to the communication module for relay towards the deployed firefighters.

Interpret received data messages through the communication module

The central data processing unit shall include a data message interpretation function that interprets received data and triggers logging, alert generation, etc.




Receive communication related alerts

The central data processing unit shall be capable of receiving and interpreting communication related alerts.

Receive power related alerts

The local data processing unit shall be capable of receiving and interpreting power related alerts (both from own communication module as received from the communication module as message from one of the firefighters.

Send out escalations

Whenever the intervention coordinating officer triggers the escalation of an alert or message via the escalation module on the visualization system.

Treat incoming escalations

The central processing unit shall be capable of translating incoming escalations received from the escalation gateway to ‘escalated alerts/messages’.

Central data log R2, R3, R4, R5

Store data locally The central data store shall be used to support all functions. It shall contains details of any data captured, any decision that has been taken, all actions that have been taken, events that have occurred, etc. across all deployed firefighters and intervention coordinating officers.

Manage data log read/write operations

The data log module shall be capable of securing conflictless data log read and write operations.

Manage storage memory overflow

If necessary, the data log module shall be capable of managing storage memory by using techniques as data compression (archiving), or deleting older data

Escalation gateway – R7

Escalate alerts The intervention coordination system shall be capable of automatically or manually escalate alerts generated at the scene towards higher hierarchically-ranked responsible intervention officers. The central terminal shall therefore be equipped with an escalation gateway applying a known interfacing protocol.

Capture incoming escalated alerts

In certain situations it may be required for the intervention coordinating officer to include in his assessment of the situation, incoming escalated alerts from other crews or higher officers. To this end the escalation gateway shall be capable of capturing incoming escalations and transfer these to the central processing unit of the intervention coordinating officer.

Data aggregation subsystem- R8

Aggregation of intervention data

Given the hierarchical constellation in which firefighter intervention are carried out (L1: 1 intervention coordinating officer per 2 or 3 binomes; L2: 1 intervention coordinating officer coordinating 4 L1 intervention




coordinating officers, etc.), the PPS system shall allow for aggregation of intervention data at multiple hierarchical levels.

Local PPS device(s) on firefighter - G1 (integration)

PPE turnout gear: integration with textile and ICT systems

Integration between the Smart PPS technological ICT equipment and standard PPE turnout gear shall be kept to limited integrative measures such as well-designed pockets, inner-shell cabling textile tubes, inner-shell velcro strips, inner-shell belts, inner-shell slip knots, etc. Outer-shell integration of ICT components with the turnout gear shall be left out of the PPS design as manufacturing cost, robustness issues, etc. cannot be solved today within the envisaged go-to-market timeframe.

Mechanical design, housing, electronic HW

The mechanical housing and HW electronics design shall be robust and shall include electromagnetic shielding (e.g. for sensors, microcontrollers,…) without implementing military grade measures.

Cabling and connectors

In case cabling is applied, cabling shall cover only inner-shell cabling and specifically designed to:

minimize impact on ergonomics

cope with different standard sizes of turnout gears

easy and fast mounting and dismounting (e.g. for repair/replace)

if designed in and left in during cleaning operations: robust and durable to meet the lifetime prescriptions

The cabling (if applied) shall be of electromagnetic shielded type. Retrofitting cabling into existing installed base of turnout gear should not be considered a feasible option.

Wireless Body Area Network (BAN)

In case the PPS solution includes wireless interconnections between multiple devices on the firefighter, this Body Area Network shall include measures to cope with the risk of interference. Tests need to be performed to make sure that the frequency spectrum is optimally used, balancing communication between e.g. sensor devices (body and environment) on the firefighter’s, localization system and radio communication towards the remote intervention coordinating terminal.

Batteries The dimensioning of the battery type and capacity shall take into account the autonomy requirements as stipulated in section 3 High-level functional requirements. Recharging multiple PPS batteries in parallel at the PPS maintenance center shall be included in the design of the PPS solution.




Weight The PPS shall add maximally 2-3 kg to the total firefighter gear, including batteries. The weight shall be well balanced on the firefighter’s body, minimally impacting

