PCP Challenge Brief - · PDF file- PCP Challenge Brief . ... Synthesis of the innovation...

SMART@FIRE-PCP model Challenge Brief

1

- PCP

Challenge Brief


2

SMART@FIRE PCP CHALLENGE BRIEF

CONTENTS AMENDMENT SHEET

Amend. No. Issue Date Amendments Initials Date

0 02/2014 Review

1 02/04/2014

2 18/05/2014


3

Contents Contents ............................................................................................................................................. 3

Definitions .......................................................................................................................................... 4

1 Background and preparation of the Smart@Fire PCP ................................................................. 5

1.1 Positioning of the PCP-tender ................................................................................................. 5

1.2 Pre-commercial Procurement in phases ................................................................................. 6

Preliminary stage: Needs assessment, defining end-user requirements, state-of-the-art ............. 6

First stage: Innovation Platform as market consultation instrument ............................................. 6

Second stage: Joint Pre-Commercial Procurement: development of innovative Smart@Fire

Personal Protective Systems ........................................................................................................... 7

Third stage: Final Joint Procurement of Smart PPS ......................................................................... 7

1.3 Preliminary Stage: Needs Assessment – Priority User needs .................................................. 8

1.4 Preliminary Stage: The State-of-the-Art .................................................................................. 9

Context ............................................................................................................................................ 9

Approach and results....................................................................................................................... 9

Main challenges to be tackled in the scope of Smart@Fire beyond the state-of-the-art. ........... 10

1.5 First Stage: The market consultation - Innovation Platform ................................................. 11

Timing ............................................................................................................................................ 11

Objectives ...................................................................................................................................... 11

Synthesis of the innovation platform insights ............................................................................... 12

Conclusions of the innovation platform ........................................................................................ 13

2 Smart@Fire Challenge: scope of the Pre-commercial Procurement Tender ............................ 14

2.1 General objective of the PCP tender: development of a prototype and first batch of testable

products ............................................................................................................................................ 14

2.2 Plan of attack ......................................................................................................................... 14

2.2.1 Solution exploration phase................................................................................................... 15

2.2.2 Prototype Development phase ............................................................................................ 16

2.2.3 Production and testing phase of 1st batch............................................................................ 16

2.3 Smart@Fire PPS pre-commercial tender scope .................................................................... 19

2.4 PPS prototype design constraints.......................................................................................... 22

3 Appendix 1: Functional Requirements ...................................................................................... 24

3.1 Chapter structure .................................................................................................................. 24

3.2 Priority use-cases in scope of Smart@Fire PCP Tender ........................................................ 25

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

3.4 Functional architecture of the Smart@Fire PPS in scope of the PCP Tender ....................... 31


4

Actors............................................................................................................................................. 33

Functional building blocks enable key use-cases .......................................................................... 34

Functional Requirements of the functional building blocks ......................................................... 36

Definitions Personal Protective System (PPS): 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. The PPS includes (non-exhaustive

list) : Personal Protective Equipment (PPE), non PPE clothing (i.e. non certified 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.

Throughout the document PPS may also be referred to as smart PPS, highlighting the technological

ICT aspects

Throughout the document the scope of the PCP tender is referred to as PPS nerve system, an

associative term reflecting both the standard PPE turnout gear and core ICT subsystems like

communication network and data transfer, feedback mechanisms towards the firefighters and

intervention coordinating officers, and intelligent processing units monitoring measured parameters

and generating alert recommendations.


5

1 Background and preparation of the Smart@Fire PCP This chapter provides an overview of the process applied to identify the functional requirements of

the Smart@Fire pre-commercial tender scope.

1.1 Positioning of the PCP-tender Few public services exist where personal safety is more important and the potential for technological

innovation to improve the provision of services is higher than with the fire fighters. The introduction

of ICT solutions (sensors, processors, cameras, wireless transmission...) in the personal protective

system of the fire fighters is complementing the textiles they are wearing to a smarter integrated

system, and can thus greatly increases both their own safety, the safety of people trapped in a fire

and the effectiveness of their intervention and most of all: it can save lives!

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 practical day-to-day use. While many

technological approaches and initial building blocks exist in different maturity stages, first

technological advancements are finally finding their way into this field. Today however, for fire and

rescue operations there is no complete system on the market, due to the specific trade-offs of the

fire and rescue niche:

1. State-of-the-art problems like indoor penetration of communication and localization are broader technological problems than just for fire and rescue applications. As such in affiliated research projects and commercial system developments, more attractive sectors such as defense, security, retail or utilities are chosen by manufacturers.

2. The fire and rescue market consists of a fragmentized procurement landscape with in general rather limited budgets (at least compared to military, security, etc.). Under these conditions it is hard to unite on selected user requirements and push these onto vendor development roadmaps.

3. The operational environment of the firefighter varies from a complex intervention in an urban confined environment to a forest fire in an open area to a technical intervention on the highway. All these specific conditions have a common need for an underlying system architecture (for communication of data for example). However, this architecture should be made flexible to allow for other functional configurations, which is under normal market conditions not easily achieved.

4. These user requirements cover all together robust operation, easy maintenance and high performance, at relatively low cost. These trade-offs are just not simply balanced.

In Smart@Fire we start 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. While procurers, fire

brigades and first responders are capable of describing the desired outcome or effect of an innovative

solution, a regular procurement exercise will not lead to a solution. Other procurement instruments

may provide a better fit, such as PCP which has the potential of spurring suppliers to enter into an

R&D development.

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;

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

favorable to research and innovation”, 2005


6

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 not only needed but also required in order

to achieve the goals of a PCP.

1.2 Pre-commercial Procurement in phases For the Smart@Fire-PCP we adopted a methodic approach, covering following subsequent stages,

described hereafter:

Preliminary stage: Needs assessment, defining end-user requirements, state-of-the-art

First stage: Innovation Platform as market consultation instrument

Second Stage: Joint Pre-Commercial Procurement: development of innovative Smart@Fire

Personal Protective Systems in three stages (Solution Exploration, Prototyping, Test series of

first products)

Third Stage: Final Joint Procurement of Smart PPS

In subsequent chapters of this document the syntheses of the outcomes obtained through the needs

assessment, state-of-the-art-study and innovation platform are described.

Note that the current tender, while providing an overview of the insights captured during the

preliminary and first stage, in essence only reflects the second stage: Joint Pre-Commercial

Procurement.

Preliminary stage: Needs assessment, defining end-user requirements, state-of-

the-art

A needs assessment has been performed in order to detect updated end-user requirements and

innovation expectations of the purchasing partners (fire fighters brigades/ first responders/ central

procuring entities). In the proposed methodology, innovation is driven by the end-user, more in

particular the end-user requirements and needs. It is important to perfectly understand these pain

points and fully describe new functional solutions, existing alternatives and quantified added value.

From a technological point of view a state-of-the-art study is carried out to allow defining the actual

highest level of development in the sector. Given the numerous projects and studies concerning the

development of Smart PPS that have been carried out during the past decade, this phase started by

going through these works in depth, gaining insights, and distilling all elements that may lead to a

pin-point formulation of the firefighter’s real and unanswered needs.

The outcome and findings of this phase allowed setting up the Innovation Platform.

First stage: Innovation Platform as market consultation instrument The Innovation Platform has been organized as a consultation platform, bringing together the buyer

side (the public purchasers expressing a specific need or request) and the supplier side (private

companies, R&D organizations, Research Centers, industry sector organizations) in a series of plenary

meetings, group work sessions and bilateral contacts. The primary goal of an Innovation Platform is

the identification of the innovation potential form an end-user perspective and from a technological

point of view. The convergence between good understanding of and access to the state-of-the-art

with the innovation expectations (end-user requirements of fire fighters and first responders) kept in

mind allowed us to identify the innovation potential.

By setting up a consultation platform a bridge is created between the demand and the supply side,

and an opportunity emerges for a structured interaction between the market and contracting

authority. The suppliers acquire knowledge about the interest and intentions of the procurers. On the


7

other side the procurers obtain the necessary information to evaluate whether their own needs are

matching with the possibility for the market (suppliers) to fulfil these needs.

Second stage: Joint Pre-Commercial Procurement: development of innovative

Smart@Fire Personal Protective Systems The findings and insights gathered throughout the Innovation Platform have been translated into a

final report and allowed the preparation of the Joint PCP. The current PCP tender documents cover

primarily the prototype scope, the priority user requirements to address, functional requirements of

the underlying prototype modules, etc. The objectives of this phase are organized in 3 phases:

1. perform solution exploration and design: during this stage of 4 months, a number of selected

suppliers (or consortia of suppliers) further elaborate the detailed design of their proposed

solution (or set of solutions).

2. develop joint-workable prototype(s): during this stage of typically 8 months, the chosen

suppliers with the best solution design (as assessed by an evaluation committee) develop their

own prototypes in parallel.

3. produce and test initial batch of finalized PPS prototypes ( (10 items): during this stage of

typically 6 months, at least 2 remaining suppliers remain to ensure a future competitive

market. Their final productized solution batch of 10 items is validated through field tests.

Note that suppliers which are not withheld throughout the evaluation and selection during the Joint

PCP can still participate in the Final (Commercial) Procurement call.

Section 2.2 ‘Scope of the Smart@Fire PCP: plan of attack’ elaborates these stages and affiliated

timeline/activities/deliverables.

Only this stage is reflected upon in the current tender launch.

Third stage: Final Joint Procurement of Smart PPS A joint procurement will be placed by the project partners and other joining procurers of Smart PPS

within the European Union to acquire these newly developed innovations in commercial volumes. It

is emphasized that this stage is not a part of the current Pre-Commercial Procurement.


8

1.3 Preliminary Stage: Needs Assessment – Priority User needs For the determination of needs and requirements of the end users, a combined approach has been

applied:

- large-scale survey

- in-depth discussion sessions with user groups

The survey has been sent to approximately 4.000 contacts from all Member States of the European

Union. The survey received 961 end users responses from 16 EU member states.

In parallel, in-depth discussion sessions were organized together with representatives from fire

brigades from Belgium, UK & France to list firefighter needs with regards to smart PPS and starting

from the vision below (as expressed by the fire fighters themselves):

“We are looking for a solution that allows

to monitor and measure the environment (persons, equipment, external conditions)

to determine the hazard-level (safe, hazardous, threatening)

by both passive (running in background) and active (deployed on demand) systems

that translate in alerts or alarms being given

and accordingly adjust the safety by whatever means necessary (e.g. textile)

so that safety and comfort are optimally balanced

irrespective of the context (fire in building, fire in forests, highways, …)”

A list of 54 use cases was collected from representatives of different user groups representing the

actual user needs. The added value and relative priority of use cases were estimated by fire brigades

themselves. From Belgium ~20 officers/fire fighters from different cities participated, in France ~15

officers/fire fighters from dept. Bouches-du-Rhône, and in UK ~35 officers/fire fighters from all over

UK.

By using the Planning Poker methodology, use cases have been objectively validated & prioritized as

the method stimulates people to voice their opinions, thoughts and concerns. This way,

drivers/reasoning behind use case validations are revealed and understood.

The conclusions of the needs assessment are unfolded hereafter.

In conclusion, a smart PPS is highly innovative for the end-users. End-users encompass different

actors, the firefighters, intervention coordinating officer, PPS manager, etc. This is proven by the

high amount of “WOW” use-cases, signifying a high added value compared to the present alternatives

today. Next to that, these needs are common across European firefighters as high commonality is

noted between the distinctively consulted user-groups across Europe through in-depth working

sessions and via the survey. Primary user requirements hold:

- Localization of the firefighter and his team, in buildings and open areas, displayed on a map,

made available to the firefighter and the intervention coordinating officer.

- Remote parameter monitoring and historical logging, making the info accessible via an

intuitive dashboard for the officer (e.g. a map), enriched with the status of the team, their

PPS, and the environment, enabling to set thresholds, generate (automatic) alerts.

- Monitoring the environment, more in particular temperature, temperature evolution,

hotspot detection and presence of explosive gasses.

- Specific PPS requirements as: avoiding sweat being turned into steam inside the turnout

gear and active illumination to be seen as first responder.


9

- General requirements as robustness under mechanical friction, maintenance, repair,

cleaning, with easy mounting/dismounting of the ICT and ideally with self-assessment.

Use cases that were distinguished as ‘low priority’ were:

Consultation of body functions (heart rate, body temperature…) by the firefighter him-/herself

PPE enhancements such as a protective airbag, additional cooling/heating, walking markers…

Consultation of building fire detectors by the firefighter

Firefighters setting safety thresholds for themselves;

Department head setting safety thresholds.

Access for representative of internal affairs to similar information as the department head

1.4 Preliminary Stage: The State-of-the-Art

Context

The envisaged innovation as summarized by the needs assessment intends to be a breakthrough

compared to the actual field systems. Many, if not all components to be used, will be new and have

to be integrated in a way that guarantees optimal protection in real life situations. This translates

into expectations of substantial R&D to be carried out at integration level, with certain implications

and R&D at component level.

Approach and results The state-of-the-art study comprised following dimensions:

- An investigation of all projects logged within the EU and national databases to locate projects

related to smart textiles, Smart PPS, high-end sensors, life support monitoring with a focus

on final results and lessons learned.

- Execution of an IP scan, analyzing patents in order to understand the major players, recent

developments and breakthroughs...

- Evaluation of relevant recent developments published in scientific journals

- Web search to identify existing available products and suppliers

Results are conclusive. A lot of activity is spotted around the priority user needs domains of

localization, environmental sensing, remote monitoring and data relay, both in research domains as

by commercial product/system providers:

- EU and nationally funded research projects: at least 40 recent projects have been identified

regarding firefighter smart textile and/or equipment research, of which 14 are directly

related to firefighter PPS. But very few smart textile innovations come to the market, for

sure not in the area of PPE/PPS. These research projects focus(ed) primarily on:

o Positioning and localization: integration of existing localization systems using GPS,

inertia-based relative localization devices (incl. accelerometers, gyroscopes, etc.)

o Environmental sensing: primarily temperature and toxic/explosive gasses

o Physiological parameter sensing (body temperature, heart rate, breathing rate,

sweat,…) and health monitoring

o Active illumination, walking markers, and heating/cooling

o Data processing and logging to generate alerts, including simple control

functionalities for the firefighters

o Intuitive visualization

o Communication and remote alert generation

- Multiple patents in this area have been filed. However, the minority of these applications is

granted so far. These mostly European and US patents focus on:


10

o Positioning sensors,

o Environmental parameter monitoring (temperature and explosive gasses),

o Physiological parameter monitoring (body core/skin temperature, heart rate, sweat

levels, etc.),

o Communication technology and remote alert generation

o Intuitive control (UI) functions for the firefighters

- Over the last decade research into smart textiles has exponentially emerged, as indicated by

the large number of scientific publications that are found on the subject of smart textiles.

Across the more than 200 publications extracted from the online academic database Web of

Science provided by Thomson Reuter, the 50 most appearing words in the keywords are

visualized in the Wordle below.

- Multiple developed prototypes show promising results. An exploratory websearch revealed

rapidly multiple industrial initiatives active on fire & rescue applications and a multitude of

technologies. However, nearly all face a major problem of day-to-day practical usability. ‘A

suit full of working ICT is no good if you cannot wash the suit after an intervention.’

These developed prototypes primarily encompass following functionalities and technologies

o Positioning within buildings and localization of colleagues in the field

Technologies: GPS, inertial sensors, beacon/antenna-based solutions, etc.

o Environmental sensing and monitoring of temperature and toxic/explosive gasses

Technologies: standard sensor technology

o Physiological sensing and monitoring of body temperature, heart rate, dehydration

levels

Technologies: standard sensor technology

o Intuitive feedback and control functions for the firefighter

Technologies: audio, visual feedback via lights or even via Head-Up Displays, Head-

Mounted displays (but at conceptual level…), etc.

o Alert generation

Technologies: auditory sirens, auditory speech, flashing lights on sleeve/waist, etc.

o Intuitive visualization for the remote intervention coordinating officer

Graphical user interface (GUI), ruggedized laptops/tablets, etc.

o Remote intelligent data processing

Rule-based reasoning, artificial intelligence (learning, neural networks), etc.

o Communication relay

Mobile Professional Radio (Tetra), Mobile Ad-hoc Networks (Manet), Zigbee,

Bluetooth, MyriaNed, WiFi, etc.

o ICT and textile integration

Woven-in electrical fibers, glued-on cabling, integrated sensors, designed-in cabling,

etc.

o Efficient and safe power supply

IP67 safe power supply to wear underneath the turnout gear, etc.

Main challenges to be tackled in the scope of Smart@Fire beyond the state-of-

the-art. Technology wise, the Smart@Fire Project goes beyond current state-of-the-art in the following ways:


11

- Collect a comprehensive list of end-user requirements as well as technological feasibility

aspects (taking into account projected technological progress).

This has been realized in the Innovation Platform

- Identify and report on gaps and R&D needs.

This will also be realized in the Solution Exploration phase.

- Specification and building developments of actual prototypes combining departing from

state-of-the-art technologies and going beyond these on well-identified sources of

technological risk. (as explained in subsequent sections)

This will be realized in the Prototyping phase.

- Testing the feasibility of (small scale) production of complete products.

This will be realized in the Batch production phase.

This project aims to develop a final product which incorporates all the functionalities of the developed

prototypes, but which is also a completely finished, ready-to-use product through PCP. In that sense

it is complementary to previous projects by offering two novel aspects:

- Clear focus on the integrated practical usability of the developed solution. Practical

usability meaning: durability, reliability, ergonomics, in compliance with overall list of

firefighters tasks (e.g. as specified in BE by KB). Integration meaning (i) collaboration between

the different technological devices on functional level; (ii) potential integration of different

technological components into 1 housing; and (iii) intelligent coupling between the

technological devices and a traditional PPE turnout gear.

- Focus on mass production feasibility and keeping this in mind from the beginning.

In conclusion, sufficient projects, market actors, etc. have been identified which are active in the

fire and rescue field, and more in particular on the common user priorities (positioning, environmental

sensing, remote monitoring…). It is observed that nearly all identified projects, prototypes, market

actors operate internationally, beyond Belgium, France and UK. Often a direct/indirect link with

military initiatives is notified. However, as military application requirements are much more

demanding, these market solutions come at a much higher manufacturing cost, and hence out-of-

market pricing for civil applications like firefighting. These market solutions need to be redeveloped,

redirected towards fire and rescue applications and its buying market.

1.5 First Stage: The market consultation - Innovation Platform

Timing

The Smart@Fire innovation platform has been organized during the months September and October

of 2013. The final presentation of the gathered insights was held October 10th 2013.

Objectives

To better protect firefighters, the Smart@Fire project envisions the next generation Smart Personal

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

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

interpreting intelligence, intuitive audiovisual feedback, smart textiles, etc. in order to successfully

address all the priority user needs. However, not all these functionalities are necessarily withheld in

the scope of the smart PPS pre-commercial tender, given the PPS prototype only focuses on a well-

defined scope, delineating the innovation potential.

Principal objective of the innovation platform is to determine these priorities of a smart PPS

prototype throughout the innovation platform discussion sessions with demand and supplier side. The

priorities are presented hereafter.


12

Synthesis of the innovation platform insights

A smart PPS holds a high innovation potential from technological perspective. This innovation

potential has been identified across the different angles of a smart PPS, in line with the key user

requirements, listed below:

Focus area 1: ICT localization systems embedded in PPS

Focus area 2: PPS sensors/active subsystems and their integration in smart textiles

Focus area 3: ICT solutions for remote connectivity & visualization systems in PPS

Focus area 4: Integration of ICT solutions with textile

Platform sessions focusing on these areas allowed understanding the vendors’ capabilities to satisfy

the most important & commonly shared user needs. The common needs in terms of robustness &

maintainability have been applied in all sessions as a boundary condition. If necessary, all constraints

imposed by any of the procurers’ countries (i.e. the minimum requirements set), have been taken

into account in a similar way.

Putting these angles together, the overall innovation potential of a smart PPS resulted in a number

of clustered challenges, of which 1 principal and 4 smaller, summarized below.

CHALLENGE 1: PPS central nerve system: system architecture, communication, localization &

interfaces

Challenge 1 covers multiple elements listed hereafter. For each element a number of insights are

described, reflecting the main sources of complexity.

The PPS central nerve system architecture:

Communication network with sufficient indoor penetration and near real-time update rate

towards the intervention coordinating officer

Balanced trade-offs between distributed and central processing, scalability of system, local

performance vs. remote responsiveness (online vs. offline operation), interfaces, etc.

Limited integration with textile (underwear, turnout gear, …):

Woven-in, layered-on ICT-textile integration comprises too many risks w.r.t manufacturing

costs, durability, etc. and is left out of the scope of the PCP tender. Limited integration

between the ICT subsystems and the standard turnout gear is preferential.

Cabled and/or wireless. When cabled: easy mounting/replacing of cables/connectors;

durability of cables/connectors; dealing with different turnout gear sizes; integrating UIs.

When wireless: limiting interference; easy start-up and self-assessment of correct operations

via minimal # UI’s

Electromagnetic shielding of the different devices (sensors, processing unit,…), without

implementing military-grade measures.

Localization engine:

A hybrid localization system (preferentially GPS with inertial subsystem) with limited indoor

drift.

A relative track & trace map, enabling ‘meet point’ and ‘recovery path’ instructions.

Available Cartesian coordinated maps (e.g. Google maps) used as overlay.

Beacon-based solution instead of inertial at increased risk, principally fast & accurate

deployment and TCO.

Intuitive user feedback (restitution, visualization):

For the intervention coordinating officer: intuitive UI dashboard, conform way of working.


13

For the firefighter: multimodal combination of audio, simple UI (button/lights) and haptic

belt. Risk reduction should focus on automated feedback modality selection and ergonomic

use.

Coupling via defined application interfaces (e.g. Bluetooth application profile) with

(Standalone) environmental temperature measurement device

Physiological monitoring device

Optional, when available: (standalone), cheap, simple and robust explosive gas detector (e.g.

indicating the presence of explosive gasses without measuring ppm details)

CHALLENGE 2: Sweat absorbing multilayer underwear

A pure textile issue, needing effort to convince firefighters and procurement agencies to review

tenders and firefighters’ comfort balance (e.g. skin resistance). Note that it is not the goal to develop

a new better performing sweat absorbing multilayer material, these materials exist. Underwear in

this context reflects anything worn underneath the turnout gear.

CHALLENGE 3: IR thermal hotspot detector

Finding the balance between a cheap, miniature IR thermal imaging sensor/camera with relevant

resolution and detection range in high temperature environments holds significant risk.

CHALLENGE 4: HMD/HUD firefighter visualization system

Providing visual feedback to the firefighter via helmet mounted displays (HMD) or head-up-displays

(HUD) in the helmet visor holds major risks in balancing trade-offs between cost, ergonomic use

(brightness, contrast, “see-through”, etc.), robustness.

CHALLENGE 5: “BE SEEN” omnidirectional active illumination

Active illumination to achieve omnidirectional “be seen” could be simply solved via a cheap,

standalone clip-on/Velcro system (limited integration with textile). The risk is to make it usable to

allow for easy operation (somewhere fixed on the firefighter suit), but not being destroyed in an

intervention due to the increased temperature or mechanical friction. An alternative cabled solution

impacts design and integration complexity (durability of connectors, cabling, etc.).

Note that explosive gas detection and physiological monitoring are not withheld within the innovation

potential from technological perspective of a smart PPS, as for these building blocks mature

technological solutions exist on or close to the market. It is not the goal to develop a next generation

of better, smaller, cheaper explosive gas detectors or physiological monitoring devices. The real

added value is the coupling with the PPS central nerve system, captured in Challenge 1.

Conclusions of the innovation platform

The conclusions of the Smart@Fire innovation platform situate on three levels:

- As first conclusion: a smart PPS is highly innovative for the end-users, as indicated by the

high amount of high-value use-cases.

- As second conclusion: a smart PPS holds a high innovation potential from technological

perspective, as described in previous section.

- As third and final conclusion, given the high innovation potential both in terms of added

value for the end-user as in terms of risk from technological and implementation perspective,

significant research and development effort is needed to reduce the risks associated to

the technologically innovative elements to enable the high-value use-cases for the end-

users, firefighters and officers. As today a commercial smart PPS is not available on the fire

and rescue application market, it is recommended to initially launch a pre-commercial

development phase. During this phase, focus is laid on reducing these risks with limited

means.


14

In consensus with the end-users (i.e. firefighters and affiliated public procurement agencies) and the

European Commission, the priority challenge for the PCP tender scope covers primarily CHALLENGE

1, PPS central nerve system (incl. standard turnout gear ‘integrated’ with ICT subsystems covering

system architecture, communication, localization, visualization, interfaces, etc.). CHALLENGE 2,

sweat absorbing multilayer textile solution, is left out as being a pure textile challenge. Regarding

CHALLENGE 3 and 4, the IR thermal hotspot detector and the HMD/HUD firefighter visualization

system, it is recommended to dedicate a similar but different project to solving these. CHALLENGE

5, “BE SEEN” omnidirectional active illumination, qualifies to be withheld within the minimal scope

of the prototype, but it is currently left out, taking into consideration the project budgetary and

timing constraints.

2 Smart@Fire Challenge: scope of the Pre-commercial

Procurement Tender

2.1 General objective of the PCP tender: development of a prototype and

first batch of testable products Developing a prototype aims at solving the primary sources of risks or implementation complexities

during a pre-commercial phase and clearing the obstacles in order to launch a subsequent traditional

final procurement procedure. Solving/reducing the sources of risk implies addressing these

complexities on a clever and cost-effective manner in a reasonable timeframe without jeopardizing

the innovation potential and added value for the end-user. That is the essence of a prototype. Al the

classical, expensive and exhaustive effort on known implementation/development activities is

referred to the development process of the final product. All aspects of a PPS bearing too high risk

are not kept in scope, as it is unlikely to reduce the associated implementation complexities on rather

short notice.

It is recommended to adopt an iterative approach during this prototype development track of building

an integrated solution. Incremental, realistic steps should be made towards the final PPS prototype.

During the development of the prototype, it should be kept in mind that the prototype as such is not

the final deliverable of the PCP tendering procedure. In a third phase, the prototype should be further

elaborated into a first batch of practically testable ‘products’.

2.2 Plan of attack In order to successfully realize the ambitious potential of the project, the necessary budgets and

efforts will have to be put forward. From the discussions with industry experts, it is noted that a

number of distinct technologies and building blocks seem to exist in different maturity stages (R&D

Demonstrator, Prototype, Commercial Product). The innovation platform learned that significant

research and development effort is needed to reduce the risks associated to the

transformation/elaboration of these partial building blocks/technologies and integration into to a

working practically usable prototype and first product batch, enabling the high-value use-cases for

the end-users, primarily the firefighters and the intervention coordinating officers.

As a result of the previous minimal scoping, the PPS pre-commercial tender scope covers CHALLENGE

1, the PPS central nerve system. During the pre-commercial development phase this minimal scope

will be further elaborated to perfectly respond to the needs of the firefighters. Elaboration involves

solution exploration, prototype development and producing a first batch of test products,

continuously balancing focus between reduction of the technological risks while securing the added

value as described by the high-value use-cases is effectively realized.

The plan of attack with envisaged timing, key activities and deliverables are presented below:


15

The envisaged timing of the subsequent phases is:

- Solution exploration phase: 4 months

- Prototype development phase: 8 months

- Creation of first batch of prototypes (10 items): 6 months

Following sections elaborate on the required activities and expected deliverables of the subsequent

phases. In his answer, the supplier shall further specify how these activities will be fulfilled in his

plan of attack.

2.2.1 Solution exploration phase

Selection of tenderers

Selection bases on the current pre-commercial procurement tender with stipulated awarding criteria.

Timing

The Solution Exploration phase is launched after selection of suppliers (or consortia of suppliers) via

the PCP tender awarding procedure and spans 4 months.

Starting point

The starting point of the Solution Exploration phase is the supplier’s answer to the awarding criteria

of the PCP tender. In essence, a supplier’s answer to the awarding criteria is in fact an initial iteration

of the solution design.

Key activities

Main objective is to elaborate the initial design of the supplier’s proposed solution (or set of solutions

in case multiple valid conceptual options are being distinguished) to a detailed design. In order to

establish this progress, a number of key activities are recommended to be performed:

- Understand the user needs: as explained in detail throughout the PCP tender documents and

the additional reports found on the Smart@Fire website.

- Deepen insights in user needs (via contextual inquiry interviews): given the user needs have

been captured using use-cases, they can be further deepened by setting up user focus groups

or interviews to fully grasp a firefighter’s context, pain points, needs, way of working,

procedures to follow, etc.

- Elaborate initial functional spec: based on the initial solution idea, the supplier can already

update significant parts of the functional requirements based on in-house prior knowledge.

- Elaborate sources of risks (as identified during Innovation Platform): assess the identified

sources of risk with internal expertise.

- Collect ideas of solution concepts: set-up brainstorm sessions to come up with solutions to

creatively overcome potential sources of risk.

- Screen solution concepts on technical feasibility (high-risk elements), business case analysis:

further assess the solution ideas towards feasibility using websearch and reasoning,

simple/cheap tests, etc., impact on value creation vs. manufacturing cost (business case)

- Select best solution concept(s) to elaborate further: final assessment or merge of multiple

parallel ideas of solutions to come up with 1 or more ‘final’ solution designs.

- Detail functional design specs for each concept: wrap-up of all gained insights, translated in

again more detailed functional design specifications of the envisaged solutions.

Deliverable

The deliverable of the Solution Exploration phase covers a complete report describing the final

solution design(s), with elaborated detailed functional requirements, ready for prototyping.


16

2.2.2 Prototype Development phase


Selection for continuation to the next phase bases on up-to-date answers provided by the tenderers

on the awarding criteria of the PCP tender (given the gained insights and deliverables of the previous

phase).

Timing

The Prototype Development phase is launched after selection of suppliers (or consortia of suppliers)

via the PCP tender awarding procedure for this phase and spans (maximum) 8 months.

Starting point

The starting point of the Prototype Development phase are the supplier’s deliverables of the Solution

Exploration phase: a full report on the final solution design with elaborated functional requirements,

ready for prototyping, and detailed answers to the awarding criteria of the PCP tender. Suppliers are

selected via an intermediate evaluation and selection milestone. Note that the awarding criteria do

not change in between the phases, but merely the relative importance of the different criteria evolves

as the PPS solution gains maturity.

Key activities

Main objective is to develop the prototype departing from the final design of the supplier’s proposed

solution (or set of solutions). In order to establish this progress, a number of key activities are

recommended to be performed:

- Prioritize sources of risk in solution concept(s), as the final solution design shall still contain

certain issues, uncertainties w.r.t. technological performance for example. Some of these are

more impacting and should be tackled first.

- (Identify non-overlapping development sets: in case the supplier desires to apply the

principles of set-based design and prototyping)

- Apply an ‘agile-based’ development process, performing incremental, iterative risk reducing

sprints while safeguarding added value for the user. Each sprint should focus on the prototype

delivery of a specific use-case by applying prototyping techniques as proof-of-concepts, mock-

ups, user-feedback sessions,…

- Include regular user-tests and demonstrations to capture from the beginning on real user

expectations and safeguard usability of the solution.

- Once risk is reduced to acceptable level, merge different sets in 1 final system specification

which starts to resemble a functional datasheet with details on production specifications.

- Finally, apply standard product/system development process to finally develop the final

prototype, by using techniques as waterfall with reference architecture, specified interfaces

and sub-systems and integration phase or others

- Set-up prototype tests to verify performance under test scenarios as prescribed in the

Appendix 1: Functional Requirements .

Deliverable

The deliverable of the Prototype Development phase covers a complete report describing the final

prototype datasheets and functional requirements ready for first test batch production, the prototype

solution first test results (knowing it is still a prototype, not yet a ‘product/solution’).

2.2.3 Production and testing phase of 1st batch


Selection for continuation to the next phase bases on up-to-date answers provided by the tenderers

on the awarding criteria of the PCP tender (given the gained insights and deliverables of the previous

phase).


17

Timing

The Production and Testing phase of the 1st batch is launched after selection of suppliers (or consortia

of suppliers) via the PCP tender awarding procedure for this phase and spans 6 months.

Starting point

The starting point of the Production and Testing phase of the 1st batch are the supplier’s deliverables

of the Prototype Development phase: a full report on the final prototype datasheets with elaborated

functional requirements, the actual physical prototype and test results on the prescribed testing

scenarios (keeping in mind it is still a prototype, not a ‘product/solution’ yet), and detailed answers

to the awarding criteria of the PCP tender. Suppliers are selected via an intermediate evaluation and

selection milestone. Note that the awarding criteria do not change in between the phases, but merely

the relative importance of the different criteria evolves as the PPS solution gains maturity.

Key activities

Main objective is to produce and test a first batch of ‘products’ departing from the final prototype.

In order to establish this progress, a number of key activities are recommended to be performed:

- Apply standard product/system development process (waterfall)

- Safeguard economic feasibility of large-scale production

- Set-up final tests of first batch of production items under prescribed testing conditions and

test scenarios

- Collaborate with notified bodies to perform the recommended PPS conformity assessment

procedure (as explained in the design constraints section) in line with existing standardized

testing procedure for PPE.

- Industrialize production by applying lean manufacturing principles

Deliverable

The final deliverable is a first batch of tested and assessed PPS systems (including the turnout gear).

The final datasheets of the PPS system form the basis of the final commercial tender.

Please note that the procurers will not retain ownership of the tested PPS systems.


18


19

2.3 Smart@Fire PPS pre-commercial tender scope

CHALLENGE : PPS central nerve system

The PPS central nerve system, an associative term, reflects both the standard PPE turnout gear and

core ICT subsystems like communication network and data transfer, feedback mechanisms towards

the firefighters and intervention coordinating officers, and intelligent processing units monitoring

measured parameters and generating alert recommendations. These functional modules hold the

innovation potential for the firefighters and as such form the PPS pre-commercial tender scope. Main

objective of this pre-commercial tender is, as already mentioned, to tackle, solve or significantly

reduce the affiliated complexities and sources of risk and to transform the functional concept of the

PPS central nerve system to a practically usable prototype and first batch of test products, that

effectively enable the priority use-cases for the firefighters.

While the real innovation potential lies more on practical applicability in-the-field, note that

functionalities as central data aggregation, escalation, and data storage are as well included in the

scope to build a final functional prototype and first batch of test products. These functionalities may

be performed on the technological equipment of the intervention coordinating officer, on existing

infrastructure of the firefighter truck, on additional (networked) infrastructure to be added on the

firefighter truck, in a virtual datacenter connected to the firefighter truck, or yet another

configuration (as described in the Appendix 1: Functional Requirements).

The chosen set-up shall however focus on aligning maximally with existing available infrastructure,

hence minimally adding extra infrastructure. (See Appendix 1: Functional Requirements and Awarding

Criteria IX: TCO of the solution, as stipulated in Invitation to Tender). For an exhaustive description

of the priority use-cases to enable, the functional reference architecture of the PPS pre-

commercial tender scope, the detailed functional requirements (as identified today) and the

testing prescriptions, reference is made to Appendix 1: Functional Requirements.

Note: For all details regarding the insights and conclusions on the Smart@Fire prototype scope, the

reader is also referred to the final report on the Smart@Fire website www.smartatfire.eu. The

Functional Requirements in Appendix 1 are mandatory while the other information (website, final

report etc.) only present the process to identify the functional requirements and the broader

objectives of the Procurers.

Following sections elaborate on the functional elements of the PPS central nerve system.

The PPS ‘central nerve’ system encompasses following building blocks and affiliated innovation

potential from technological perspective. In other words: the PPS pre-commercial tender scope

(prototype & first batch) comprises a number of functional modules and should aim to solve/reduce

following sources of complexity/risk.

The overall central nerve system architecture:

- Communication network with sufficient indoor penetration (sufficient to successfully realize

the envisaged test scenarios), optimized data rate, data model, data preprocessing, and near

real-time update rate towards the intervention coordinating officer (by maximizing the

scalability trade-off of deployed network nodes vs. update rate).

Different communication technologies exist, but all with different intended usage: intended

use of Professional Mobile Radio (PMR) is for trunked mode operation (TMO) and direct mode

operation (DMO) voice and limited data. Mobile ad-hoc networks (MANET) for data and

selected compressed images, Ultra Narrow Band (UNB) for small data sets at low update

frequencies.

- Setting-up the right architecture is key and holds significant risk. Main sources of risk

comprise defined the data model, setting the balance between distributed and central

processing taking into account trade-offs between local processing performance of selected

http://www.smartatfire.eu/


20

data and responsiveness when remote relay of data (e.g. in case of physiological alerts),

defining interfaces for hierarchical aggregation and escalation, building the suited data

model, allowing for online and offline operation with careful consideration of polling and

synching events, coping with the multimodality in firefighter user restitution means,

modularity allowing for coupling with new peripherals (e.g. sensors), scalability of the system,

etc.

The objective is not to develop a ‘usine-a-gaz’ allowing for endless flexibility, merely it is the

goal to ’do the right things’ allowing for some future improvement and coupling with new

peripherals. It should be thought through which future peripheral devices might be coupled.

Also start-up of the system should be in line with present routines when preparing for an

intervention and arriving at the scene. Additional manipulations by the firefighter should be

minimized.

Limited integration with textile (underwear, turnout gear, or …):

- Woven-in, layered-on ICT-textile integration implies too many risks w.r.t manufacturing

costs, durability, etc. and as such is left out of the scope of the PCP tender. 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.

- Cabled (internally in the PPE turnout gear or between the PPE turnout gear layers) and/or

wireless integration are allowed, with careful consideration of respective risks:

o when cabled: easy mounting/replacing of cables/connectors; durability of

cables/connectors; dealing with different turnout gear sizes; integrating multiple UIs.

Under the assumption that the total duration of replacing the cabling designed in into

the layers of the turnout gear can maximally take 15 minutes to not heavily impact

the workload of the PPS maintenance crew, it is key to keep cabling as simple as

possible. Ultimate goal is to reduce the risk so that a PPS maintenance responsible

can easily carry out the replacement task, without specialized help of a textile

specialist.

Durability and robustness of operations refers both to the normal operational

conditions (heat, chemicals, etc.) during interventions, as to the cleaning operations.

Throughout the lifecycle of a turnout gear (5 to 8 years), around 20 to 25 cleaning

operations are carried out, during which the turnout gear is subjected to special

treatments, like restoring waterproofness, etc. This is not easily resolved. Easy

(dis)mounting (and recuperating) the cabling could lighten the risk severance, but

connectors remain an issue, especially those used to connect external sensor devices.

As such, these externally exposed connectors are not preferential for the PPS

prototype.

Concerning the multiple sizes of turnout gear, the assumption is taken that 3 variants

will suffice for the 8 turnout gear sizes. The constraint is that impact on ergonomics

is nihil. Furthermore, ‘only’ 3 variants do not impact manufacturing costs too much.

Solutions incorporating “stretchable cables” are not envisaged given a higher risk

severance on ergonomics, durability, etc.

o when wireless: limiting interference (cfr. data connectivity); easy launch, start-up

and assurance of correct operations via minimal # UIs.

Starting up the system should be straightforward, even in case there are several

wireless interlinked devices on the firefighter. The firefighter should as fast as

possible know that the system is fully operational in line with his time to arrive on

site (order of magnitude of 5 to 10 minutes). Compared to a centralized system, a

wireless approach is more complex, especially when the aim is to restrict the amount

of UI’s to a minimum.


21

Next to start-up and launching the system operational, this should be launched in the

right configuration, with auto-detection mechanisms, etc. Again with minimal

operations/manipulations required from the firefighter. Typically to select the right

gear (and hence configuration) the firefighter relies on the intervention briefing by

the security officer.

Finally, tests need to be performed to make sure that the frequency spectrum is

optimally used, balancing communication between sensor devices (body and

environment) on the firefighter’s, localization system and radio communication

towards the remote intervention coordinating terminal.

- Electromagnetic shielding of the different devices (sensors, processing unit,…), without

implementing military-grade measures.

Localization engine:

- A hybrid localization system (GPS + inertial) with limited indoor drift is preferential. It is

agreed by the state-of-the-art industry experts that in order to achieve a limited drift of

maximum a few meters after 10 to 20 minutes without reference position update, thorough

testing should be set-up in indoor environments during fire and rescue applications. (10 to 20

minutes suffices, given the capacity of a compressed air bottle amounts around 25 minutes.)

These tests will further clarify any implications on design of the device and motion tracking

modeling. It is believed that by implementing smart measures (e.g. transferring absolute

position updates between team members or re-calibrating fast when standing still) the

required performance level can be approached, within tradeoffs of the envisaged Smart@Fire

PPS.

Of course anything is possible for the right price, given the capability of navigating fighter

jets through valleys for hours relying primarily on inertial measurement units.

- A relative track & trace map should enable ‘meet point’ and ‘recovery path’ instructions. In

case a map of the environment is available (e.g. Google maps, or offline map created by

UAVs) and the map is referenced w.r.t. absolute Cartesian coordinates, it should be used as

e.g. an overlay.

- Beacon-based solution for localization can be incorporated at increased risk in terms of ease

of deployment without losing accuracy and TCO.

Note that it is not envisaged to deploy this solution over the complete building. Merely, the

aim is to gradually, locally and virally grow the beacon network within the intervention area.

In ideal situations (reasonably vast areas or rooms with wide angle of sight) when the beacons

have been deployed in a good way, attaining an indoor accuracy of the order of magnitude of

1 meter is feasible, and hence the risk is relatively acceptable. Given that reality is often far

from the ideal situation and taking into account the human error factor in the deployment of

the beacons the real risk is estimated significantly higher and risk reduction is required.

A precondition for a fast and qualitatively good deployment of the beacons requires insight

of the firefighter in the context of the environment, e.g. to immediately determine the

needed amount and maximal spread of the beacons to deploy. As it requires lots of field trials

to train the firefighters and consolidate the approach in a reproducible deployment

procedure, the estimated risk is significant.

Intuitive user feedback (restitution, visualization):

- For the intervention coordinating officer: an intuitive User Interface (UI) dashboard, aligned

with way of working should be developed

In France for example, the way of deploying firefighters occurs as follows: per truck there is

a “penetration officer” coordinating typically 2 teams of firefighters. At a second coordination

level, 1 “group commanding officer” coordinates up to 4 penetration officers. In parallel, a

“security officer” who disposes of own firefighter couples focuses on the safety and potential

rescue of colleague firefighters. So the GUI needs to be adaptive in the level of data

aggregation/escalation and visualization.


22

- For the firefighter: a multimodal combination of audio, simple UI (button/lights) and haptic

belt should be developed. Risk reduction focuses on automated feedback modality selection

and ergonomic use (mainly of the haptic belt).

Haptic belts refer to belts worn under the turnout gear generating local vibrations to indicate

an alert, a direction to go to, etc. While commercially available and used in military

navigation tasks, the main source of risk is that the belt should not impact ergonomics and

toleration level given the stress of the intervention.

Coupling via defined application interfaces (e.g. Bluetooth application profile) with

- (Standalone) environmental temperature measurement device, as the goal of the PCP tender

is not to develop a new environmental temperature sensor, but merely interface with it via a

standardized interface.

- Existing physiological monitoring devices to capture hearth rate, breathing rhythm, etc.

- Optional, when available: (standalone), cheap, simple and robust explosive gas detector (e.g.

indicating just the presence of explosive gasses). Note that 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.

The innovation potential for the firefighters of the PPS central nerve system is captured through the

priority use-cases listed below. The objective of the PCP tender is to deliver a first batch of PPS

solutions that can effectively realize these use-cases for the end-users. (Note that in the table

below ‘ICO’ refers to ‘Intervention Coordination Officer’, ‘FF’ to firefighter, ‘T’ to temperature,

‘RCA’ to ‘Root Cause Analysis’)

For an exhaustive description of the priority use-cases, the functional reference architecture of

the PPS pre-commercial tender scope and the detailed functional requirements, reference is

made to Appendix 1:Functional Requirements.

2.4 PPS prototype design constraints It is important to know as tendering supplier that throughout the innovation platform, 2 main design

constraints have been determined, the first with respect to buying budget orders of magnitude, the

second with respect to applicable standardization and conformity assessment procedures. These

design constraints are elaborated below:

Price of PPS: Today firefighter turnout gear prices vary around 600-750€ per piece (i.e. vest,

trousers). In line with budgetary provisions, the price of the envisaged PPS final system is expected


23

to amount maximally 1500€ (order of magnitude) per firefighter PPS, including technological

components, turnout gear garment and excluding helmet, additional hardware/software (ruggedized

tablets/laptops, application servers, licenses, etc.) for the intervention coordinating officer.

This price indication provides tenderers a guideline when setting solution design trade-offs. Evidently,

not only price per PPS is important, merely the awarding criteria, as stipulated in the Invitation to

Tender document, focus on total cost of ownership throughout the lifetime of the PPS.

Standardization and guaranteeing safety: At all times the Smart@Fire PPS prototype and first batch

of products should fulfill basic health and safety requirements. For the PPE turnout gear, health and

safety requirements are safeguarded through existing directives and harmonized standard testing

procedures (EN469). These directives do not apply to smart textiles, where ICT cables, sensors and

actuators are integrated within the PPE textile.

On the other hand, for fire and rescue ICT-related products and systems, multiple levels of directives

and standards are commonly complied with by suppliers: e.g. environmental standards for intended

use in explosive environments (ATEX, IEC-Ex), radio & communication standards (RTTE), material

related standards (REACH, RoHS), etc.

Suppliers’ products shall comply with these standards and directives, by obtaining necessary

certification through test procedures via a recognized notified body ((if applicable for the intended

use).

To omit any potentially blocking discussions, in the envisaged Smart@Fire PPS system,

integration between the PPE turnout gear (textile) and the ICT technological systems is kept

to a minimum. Some ICT technological systems (such as localization device, processing unit,

batteries) may be worn underneath the inner shell of the turnout gear and can be decoupled

from the turnout gear. As such known directives and standard test procedures apply (e.g.

Ingress Protection Rating of IP67). Other ICT technological systems like sensing devices will

equally be exposed to extreme conditions, but still not really integrated with the PPE turnout

gear (as the technological risks are estimated too high). Again the different known directives

and standard testing procedures apply.

Nevertheless, in addition to the known 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). These testing procedures are elaborated upon in Appendix 1: Functional

Requirements.


24

3 Appendix 1: Functional Requirements

3.1 Chapter structure This chapter covers the mandatory requirements of the Smart@Fire PPS prototype. Each section

answers a different key question:

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

realized by the Smart@Fire PPS prototype?

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

prototype solution design?

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

architecture, given the priority use-cases to enable?

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

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

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

identified to be implemented during prototype solution design and development?


25

3.2 Priority use-cases in scope of Smart@Fire PCP Tender This section elaborates on the priority user requirements, as indicated by the firefighters (end-users)

themselves. The format used are use-cases:

As an <actor>, I can <perform an action, dispose of a system, etc>, so that <my pain point is solved

and added value is created for me>.

The key use-case are listed hereafter.

In the subsequent table, reasoning is provided why these use-cases are key for the end-users, as

consulted in interactive user-group sessions in Belgium, France and UK.


26


27

3.3 High-level functional requirements for the Smart@Fire PPS in scope of

the PCP Tender While the previous section focuses on the key functional requirements from an end-user point of view,

the current section aims at clarifying what this implies on functional requirements for the Smart PPS

Solution to be designed & developed.

Following high-level functional requirements have been identified. These high-level functional

requirements should be considered by tenderers as overarching requirements, to be met by the

Smart@Fire PPS prototype.

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


28

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

With minimal additional needed infrastructure: e.g. data aggregation servers, extra

communication antennas, etc. on the firefighter trucks.

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 Section 2.4 Design Constraints). 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:


29

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.

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.

These functional field tests will be set up near the end of Phase 3 at one of the procurer’s

test sites (SDIS13).

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


30


31

3.4 Functional architecture of the Smart@Fire PPS in scope of the PCP

Tender Section 3.2 presents the priorities for the end-user, section 3.3 explains what this implies for the

solution to be developed, but still high-level. The current section elaborates in all known detail, the

functional architecture and specifications of the Smart PPS solution to be developed. These are the

mandatory solution requirements to fulfill with the Smart@Fire prototype.

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 (with ‘S’ for sensors,

‘I’ for intelligence, ‘R’ for relay, ‘G’ for integration aspects):

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. These modules are temperature sensing module, explosive gas

detection module, physiological monitoring module. As stated in section 2.3 on the pre-commercial

tender scope, the selection of the modules themselves are NOT mandatory requirements, only the

capacity of the Smart@Fire PPS prototype to couple with them via known interfacing protocol.


32

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)


33

Relay R7 Escalate

Relay R8 Aggregation

Relay R9 Alerts

Relay R10 Communication

In subsequent sections, the functions of the functional building blocks will be reflected on in detail.

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


34

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.


35


36

Functional Requirements of the functional building blocks

The functional architecture is further detailed below: for each functional building block, the main

Functional Requirements as identified today are listed.


37

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

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


38

requirements described in section 3.4.3. One Smart@Fire PPS prototype solution must address these

mandatory requirements

Functional

building block

Function Functional Requirements

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.


39

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:

orientation, body

posture, etc.

The localization system shall measure the relative

orientation (α) with respect to an absolute reference, e.g.

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



40

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


PPS prototype will not develop a new environmental

temperature sensor, but merely interface with it via a


Output

environmental

temperature

The standalone 3rd party environmental temperature sensor

should output the environmental temperature via


profile (wireless e.g. Bluetooth).

The output data should simply include the environmental

temperature.



Environmental

monitoring

S9 – explosive

gasses

Measure

environmental

explosive gasses


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




41

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


profile (in case localization system and local processing

device are separate HW devices with wireless or wired

interconnection).

Capture

physiological

monitoring

parameters


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,


42

dehydration level, dehydration level accuracy, and

potentially heat stress or skin burn alarm probabilities or

flags.



Capture

environmental

temperature

measurements


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.



Capture

environmental

explosive gasses

detection


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.



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.


43

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.


44

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


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.


45

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.


46

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.


47

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.


48

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


49

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.


50

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


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.

The central data storage may be performed on the

technological equipment of the intervention coordinating

officer, on existing infrastructure of the firefighter truck, on

additional infrastructure to be added on the firefighter

truck, in a virtual datacenter connected to the firefighter

truck, or yet another configuration.

The chosen set-up shall however focus on aligning with

existing available infrastructure, hence minimally adding

extra infrastructure. (see also high-level functional

requirements).


51

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,

and ideally using existing available infrastructure

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.

The data aggregation may be performed on the

technological equipment of the intervention coordinating

officer, on existing infrastructure of the firefighter truck,

on additional infrastructure to be added on the firefighter

truck, in a virtual datacenter connected to the firefighter

truck, or yet another configuration.

The chosen set-up shall however focus on aligning with

existing available infrastructure, hence minimally adding

extra infrastructure. (see also high-level functional

requirements).

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,


52

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.


53

The weight shall be well balanced on the firefighter’s body,

minimally impacting

PCP Challenge Brief - · PDF file- PCP Challenge Brief . ... Synthesis of the innovation...

Documents

Transcript of PCP Challenge Brief - · PDF file- PCP Challenge Brief . ... Synthesis of the innovation...