Realtime locatie- en conditiebepaling van manschappen

Challenge: Hoe kunnen we realtime de locatie en conditie van brandweermannen in gebouwen bepalen

Context & urgentie

Bij binneninzet werken brandweermensen onder extreme omstandigheden: dichte rook, hitte, instortingsgevaar en nul zicht. In die complexiteit is snelle en eenduidige beeldvorming cruciaal: de bevelvoerder moet weten wie waar is, wat ze zien/doen en hoe het met ze gaat. Vandaag ontbreekt dat vaak, omdat GPS binnen faalt en verbale meldingen op een gedeeld radiokanaal tot ruis of misinterpretatie leiden. Gevolg: vertraging, onduidelijkheid en onnodig risico voor hulpverleners.

Hoe kunnen we realtime de locatie en conditie van brandweermensen in gebouwen bepalen.

Jouw oplossing geeft ons bij voorkeur inzicht in:

1. Realtime de positie (x, y, z/floor) van manschappen.
2. Conditie-indicatie (bijv. werklast/temperatuur/hartslag/air-time of vergelijkbare proxy’s) om proactief te kunnen wisselen of terugtrekken.
3. Eenduidige communicatie door locaties & observaties te verankeren aan ruimtes/deuren/hoogtes i.p.v. alleen verbale duiding.
4. Data die gebruikt kan worden, na de inzet, voor debriefing en training (tijdlijn + pad + beslissingen).

Primaire use-cases

• Binnenbrand in complex pand: bevelvoerder ziet live wie via welke toegang naar boven/beneden gaat, welke deur/ruimte is bereikt en of de vuurlast daar te hoog is. Minder spraakverwarring over “de slaapkamer links” of “die trap” – iedereen kijkt naar hetzelfde beeld.
• Zoekactie/vermijding van vermissing: bij verlies van oriëntatie (slang kwijt, nul zicht) geeft de oplossing richting/fallback, en laat de bevelvoerder de laatst-bekende positie/route zien.
• Groot incident / langdurige inzet: conditie-indicator per teamlid helpt tijdig wisselen voordat oververhitting of uitputting optreedt.
• Verkenning buitenom/grootschalig terrein: bij storm- of industrie-incidenten kan de Bevelvoerder zien waar verkenners lopen en sneller “over hetzelfde praten”.

Scope van de challenge

1. In scope: dit zouden ons inziens oplossingsrichtingen kunnen zijn
   • Bijvoorbeeld wearables of geïntegreerde modules (helm, pak, ademlucht, armband e.d.) die locatie & eenvoudige conditie-indicator levert.
   • User interface toepassing voor bevelvoerder (in bestaande tablet/MDT) met kaart-/plattegrond- en 3D/floor-weergave.
   • API/gegevenslaag die koppelt met het operationele MDT (tablet) en de bestaande operationele suite.
   • Mechanismen voor privacy-by-design (minimale data, rolgebaseerde toegang, versleuteling) en veilig loggen voor evaluatie.
2. Out of scope: Oplossingsrichtingen die het vervangen van het volledige commandosysteem vereist of oplossingen die afhankelijkheid van vaste gebouwinfrastructuur hebben.

Ontwerpprincipes

• Low cognitive load: geen extra rompslomp; werkt “by default” of met één handeling.
• Integreren, niet vervangen: sluit aan op operationele MDT; geen parallel systeem.
• Graceful degradation: inzet kan doorgaan als de oplossing uitvalt.
• On-demand detail: standaard overzicht voor bevelvoerder; detail pas tonen wanneer nodig (calm tech).
• Robuust & field-ready: hitte/rook/water/impact-bestendig; handschoen-proof; batterijen/air-time in lijn met inzetduur.

Functionele eisen

1. Locatie
   • Realtime x/y en z/floor; indicatie van route/“kruimelspoor”.
   • Werkt zonder vooraf geïnstalleerde gebouwinfrastructuur; kan wél optioneel externe signalen gebruiken als ze er zijn.
   • Fallback bij signaalverlies (dead-reckoning/traagheidsdata) en plausibiliteitscheck (driftschatting).
2. Conditie
   • Lichtgewicht indicatie (bijv. groen/oranje/rood) op basis van beschikbare, veilige proxies (bijv. hittestress/ademlucht/arbeidsbelasting).
   • Voorkeur voor proactieve signalering
3. Weergave & User Interface
   • Eenduidige kaart/floor-visualisatie (2D + hoogte-indicatie, bij voorkeur ook 3D-overlay waar mogelijk).
   • Labeling van deuren/ruimtes en pad, zodat verbale meldingen (“bij deur A”, “trap B”) ondubbelzinnig zijn.
   • Rolgebaseerde toegang: bevelvoerder ziet eigen eenheden; OvD ziet meerdere bevelvoerders en kan doorklikken naar teams.
4. After Action Review
   • Tijdlijn van inzet, routes, events (meldingen, drempeloverschrijdingen) voor training/debriefing.

Niet-functionele eisen

• EMC-ontstoord: geen storing op communicatiemiddelen; aantoonbare Electromagnetic Compatibility.
• Beveiliging & privacy: end-to-end versleuteling, minimale persoonsdata, logging onder toezicht en volgens wet- en regelgeving.
• Performance: latentie die praktisch “>= realtime” aanvoelt (richtwaarde: < 1–2 s voor positie-update); batterijlifetime passend bij inzet.
• Betrouwbaarheid: failsafe gedrag, duidelijke degradatie-status, offline modus bij netwerkverlies, store-and-forward.
• Interoperabiliteit: open API’s; gegevenslaag koppelbaar aan operationele MDT (tablet) en gelaagde autorisatiestructuur.

Integratie & architectuur

• MDT-koppeling verplicht (operationeel tablet/suite). Geen vendor lock-in.
• Data-lagen: kaart/plattegrond (eventueel verouderd) + live positie + events + (optioneel) gebouwinformatie/aanvalsplan.
• 3D/floor: hoogtemeting en etageherkenning (barometrisch/IMU/algoritmisch).
• Onbetrouwbare plattegronden: ontwerp tolereren dat tekeningen verouderd zijn; laat gebruikers snel “corrigeren/annoteren” in het veld.

Randvoorwaarden vanuit operatie

• Geen extra administratieve handelingen tijdens de eerste minuten; idealiter automatisch of met enkelvoudige bevestiging.
• In te bouwen in bestaande uitrusting (pak/helm/ademlucht/voertuig) of als minimale extra wearable.
• Geen harde afhankelijkheid: uitval mag inzet niet blokkeren.
• Werkt met handschoenen, in rook, bij lawaai; duidelijke haptische/visuele signalen i.p.v. alleen audio.

Wat we niet zoeken

We zoeken geen advies. We zoeken een Startup die de oplossing na de mvp en pilot fase ook zelfstandig kan vermarkten naar meerdere veiligheidsregio’s.

Oplossingen die slechts werken met vooraf geïnstalleerde beacons/wifi in elk gebouw.

Een volledig nieuw commandoplatform los van MDT, of systemen die de bevelvoerder overspoelen met data.

Updates

25-09-2025 Updates will be published at 21th of October

21-10-2025 During the Q&A session, the following questions were asked: (see english text below description)

Kan de brandweer gebruikmaken van camera’s tijdens inzetten?
Vraag:
Onze technologie werkt met een camerafeed. Is het mogelijk dat brandweermensen een camera op hun helm of borst dragen, zodat wij die data kunnen gebruiken?
Antwoord:
Ja, dat kan. In Nederland wordt het gebruik van bodycams bij de brandweer al toegepast, met name voor leerdoeleinden en vakbekwaamheidstrainingen. Er is dus geen bezwaar tegen het gebruik van camera’s, mits dit duidelijk wordt aangegeven in het voorstel.

Wat zijn de belangrijkste informatiebehoeften tijdens een brand?
Vraag:
Wij kunnen op basis van camerabeelden exact bepalen waar iemand zich bevindt en waar diegene naar kijkt. Is locatie-informatie iets wat jullie helpt?
Antwoord:
Zeker. Het is voor ons cruciaal dat de leiding buiten weet waar de ploegen zich binnen een gebouw bevinden. Vooral bij complexe gebouwen is het belangrijk te weten: op welke verdieping en in welk gedeelte van het pand iemand is.

Zijn real-time informatie en AR-overlays relevant?
Vraag:
Wij kunnen informatie real-time in beeld brengen, bijvoorbeeld de status van sensoren in de ruimte. Is dat iets wat jullie aanspreekt?
Antwoord:
Ja, dat is interessant. We zoeken juist naar manieren om informatie tijdens de inzet te ontsluiten, zonder dat brandweermensen zelf iets hoeven af te lezen.

Welke data zijn belangrijk tijdens een inzet?
Vraag:
Gaat het vooral om locatie, of spelen andere factoren ook een rol?
Antwoord:
Naast locatie is ook de conditie van de brandweerman of -vrouw van belang. Door rookgassen, hitte en nieuwe bouwmaterialen ontstaan risico’s zoals hittestuwing. Het zou waardevol zijn als sensoren die fysieke conditie kunnen monitoren of signaleren wanneer er gevaar dreigt.

Moet de camera altijd aanstaan?
Vraag:
Onze techniek werkt alleen met camerabeelden. Kan dat een probleem zijn?
Antwoord:
Niet per se, maar het is wel iets om goed te overwegen.
De vraag is of het systeem altijd een actieve camera nodig heeft of dat er ook alternatieve manieren van positiebepaling mogelijk zijn. Dat is technisch gezien interessant om verder te onderzoeken.

Hoe flexibel moet de oplossing zijn qua gebouwen?
Vraag:
Wij maken 3D-scans van gebouwen. Moet de oplossing in elk willekeurig gebouw werken, of gaat het om specifieke locaties die vooraf in kaart gebracht kunnen worden?
Antwoord:
Het gaat om alle typen panden waar brand kan uitbreken.
Omdat je nooit weet waar een brand ontstaat, is het niet haalbaar om vooraf alle gebouwen te scannen. Het zou interessant zijn als jullie technologie ook zonder voorafgaande scans bruikbaar is, bijvoorbeeld door vanaf de buitenkant of via bestaande data iets te kunnen bepalen.

Hoe relevant zijn bestaande 3D-scans van gebouwen?
Vraag:
Er bestaan al veel scans vanuit vastgoedbeheer en Building Information Management. Kunnen die gebruikt worden?
Antwoord:
Ja, dat is juist interessant. Er zijn steeds meer digitale gebouwmodellen beschikbaar. Als jullie die bestaande data kunnen benutten, levert dat veel op.
Dat sluit aan bij onze ambitie om slimmer samen te werken met andere sectoren die al met gebouwdata werken.

Hoe vaak speelt rookontwikkeling een rol bij branden?
Vraag:
In hoeveel gevallen is rookontwikkeling de belangrijkste factor?
Antwoord:
In de meeste gevallen. Tegenwoordig zijn veel branden klein qua vuur, maar met grote rookontwikkeling.
Rook is vaak de reden dat er grote inzet plaatsvindt – niet de brand zelf.
Nieuwe bouwmaterialen en isolatie maken die rook bovendien dikker en vettiger, wat ook het zicht beperkt.
Dat is een belangrijk aandachtspunt voor technologie die afhankelijk is van camera’s.

Wat zou een interessante vervolgvraag zijn voor jullie oplossing?
Antwoord:
Het is interessant om te onderzoeken of jullie zonder camera’s toch relevante data kunnen genereren.
Bij de brandweer zijn wij zelf de “ogen”, dus de vraag is of de technologie kan meebewegen zonder altijd een lens nodig te hebben. Dat is een mooie technische uitdaging.

English Version

Context & Urgency

During interior firefighting operations, firefighters work under extreme conditions: thick smoke, heat, collapse risk, and zero visibility. In such complexity, rapid and consistent situational awareness is crucial — the incident commander must know who is where, what they see/do, and how they are doing. Today, that clarity is often missing because GPS fails indoors, and verbal communication over a shared radio channel can lead to noise or misinterpretation. The result: delays, confusion, and unnecessary risk for responders.

The core question:
How can we determine, in real time, the location and condition of firefighters inside buildings?

Ideally, your solution provides insight into:

• Real-time position (x, y, z/floor) of personnel;
• Condition indicators (e.g., workload, temperature, heart rate, air-time, or similar proxies) to enable proactive rotation or withdrawal;
• Clearer communication by anchoring locations and observations to rooms, doors, and floors — rather than only verbal descriptions;
• Data that can be used afterward for debriefing and training (timeline + route + decision points).

---

Primary Use Cases

• Interior fire in a complex building: The commander sees live which team members are moving up/down via which access point, which door or room they’ve reached, and whether the heat load there is too high. Less confusion over “the left bedroom” or “that staircase” — everyone sees the same visual.
• Search or missing-person scenarios: When orientation is lost (e.g., lost hose, zero visibility), the solution provides direction/fallback and shows the commander the last known position and route.
• Large-scale or prolonged incident: Individual condition indicators help rotate teams before overheating or exhaustion occurs.
• Exterior reconnaissance or large-area incidents: During storms or industrial incidents, the commander can see where reconnaissance teams are and align communication more effectively.

---

Scope of the Challenge

In scope: Possible solution directions include:

• Wearables or integrated modules (e.g., helmet, suit, breathing apparatus, wristband) that provide location and basic condition data;
• A user interface for the commander (within the existing tablet/MDT) with map/floorplan and 3D/floor visualization;
• An API/data layer integrated with the operational MDT (tablet) and existing software suite;
• Privacy-by-design mechanisms (minimal data, role-based access, encryption) and secure logging for evaluation.

Out of scope:

• Solutions requiring complete replacement of the command system;
• Solutions dependent on fixed building infrastructure (e.g., pre-installed beacons or Wi-Fi).

---

Design Principles

• Low cognitive load: Works “by default” or with a single action — no added complexity.
• Integrate, don’t replace: Must connect to the existing MDT; no parallel system.
• Graceful degradation: Operations must continue if the solution fails.
• On-demand detail: Overview by default; show details only when needed (calm tech).
• Robust & field-ready: Resistant to heat/smoke/water/impact; glove-proof; battery/air-time suitable for operational duration.

---

Functional Requirements

Location

• Real-time x/y and z/floor positioning with breadcrumb-style route tracking;
• Must work without pre-installed infrastructure, though it can optionally use external signals if available;
• Fallback options in case of signal loss (dead reckoning/inertial data) with plausibility checks for drift estimation.

Condition

• Lightweight indicators (e.g., green/orange/red) based on safe, available proxies (e.g., heat stress, air pressure, workload);
• Preference for proactive alerts.

Display & User Interface

• Clear map/floor visualization (2D + height indication; ideally also 3D overlay where possible);
• Labeling of doors/rooms and routes to eliminate ambiguity in verbal reports (“at door A,” “staircase B”);
• Role-based access: commanders see their own units; the incident commander sees multiple teams and can drill down as needed.

After Action Review

• Deployment timeline with routes, events (alerts, threshold exceedances) for training and debriefing.

---

Non-Functional Requirements

• EMC safety: No interference with communications; proven electromagnetic compatibility.
• Security & privacy: End-to-end encryption, minimal personal data, logged and supervised according to regulations.
• Performance: Practically “real-time” latency (target: <1–2 seconds for position updates); battery life suitable for full deployment.
• Reliability: Failsafe behavior, clear degradation indicators, offline mode when disconnected, store-and-forward capability.
• Interoperability: Open APIs; data layer linkable with operational MDT (tablet) and layered authorization structure.

---

Integration & Architecture

• MDT integration is mandatory (operational tablet/software suite). No vendor lock-in.
• Data layers: map/floorplan (even if outdated) + live positions + events + optional building info/attack plan.
• 3D/floor: altitude detection and floor recognition (barometric/IMU/algorithmic).
• Must tolerate outdated floorplans; users should be able to quickly correct/annotate in the field.

---

Operational Constraints

• No extra administrative steps during initial minutes; ideally automatic or with single confirmation.
• Integratable into existing gear (suit/helmet/breathing apparatus/vehicle) or minimal additional wearable.
• No hard dependency — system failure must not block operations.
• Must function with gloves, in smoke, and in noise; use clear haptic/visual cues instead of audio only.

---

What We Are Not Looking For

Entirely new command platforms separate from the MDT, or systems that overwhelm the commander with excessive data.

Consultancy or advisory services — we seek a startup that can commercialize the solution independently after the MVP and pilot phases.

Solutions that work only with pre-installed beacons/Wi-Fi in each building.

Q&A update

Can firefighters use cameras during operations?
Question:
Our technology works with a camera feed. Is it possible for firefighters to wear a camera on their helmet or chest so we can use that data?
Answer:
Yes, that’s possible. In the Netherlands, the use of bodycams in the fire service is already being applied, mainly for learning purposes and competency training. There is therefore no objection to the use of cameras, as long as this is clearly stated in the proposal.

What are the most important information needs during a fire?
Question:
We can use camera footage to determine exactly where someone is and what they are looking at. Is location information something that helps you?
Answer:
Absolutely. It’s crucial for the incident commander outside to know where the teams are located inside a building. Especially in complex buildings, it’s important to know which floor and which section of the building someone is in.

Are real-time information and AR overlays relevant?
Question:
We can display information in real time, for example the status of sensors in a room. Is that something that appeals to you?
Answer:
Yes, that’s interesting. We are specifically looking for ways to make information accessible during an operation without requiring firefighters to read or check anything themselves.

What data are important during an operation?
Question:
Is it mainly about location, or do other factors also play a role?
Answer:
Besides location, the condition of the firefighter is also important. Due to smoke gases, heat, and new building materials, risks such as heat stress can arise. It would be valuable if sensors could monitor physical condition or signal when danger is imminent.

Does the camera need to be on at all times?
Question:
Our technology only works with camera images. Could that be a problem?
Answer:
Not necessarily, but it’s something to consider carefully.
The question is whether the system always needs an active camera, or if alternative positioning methods are possible. That’s an interesting technical aspect to explore further.

How flexible should the solution be regarding buildings?
Question:
We create 3D scans of buildings. Should the solution work in any type of building, or can it focus on specific locations that are mapped in advance?
Answer:
It needs to work in all types of buildings where a fire might occur.
Because you never know where a fire will start, it’s not feasible to scan all buildings in advance. It would be interesting if your technology could also function without prior scans — for example, by using data from the exterior or existing sources.

How relevant are existing 3D scans of buildings?
Question:
Many scans already exist from property management and Building Information Management. Can those be used?
Answer:
Yes, that’s very relevant. There are more and more digital building models available. If your technology can make use of that existing data, it adds a lot of value.
That aligns with our ambition to collaborate more effectively with other sectors already working with building data.

How often does smoke development play a role in fires?
Question:
In how many cases is smoke the main factor?
Answer:
In most cases. Nowadays, many fires are small in terms of flames but produce a lot of smoke.
Smoke is often the reason for large-scale deployment — not the fire itself.
New construction materials and insulation make the smoke thicker and greasier, further reducing visibility.
That’s an important consideration for technologies that rely on cameras.

What would be an interesting follow-up question for your solution?
Answer:
It would be interesting to explore whether your technology could generate relevant data even without cameras.
At the fire service, we are the eyes — so the question is whether the technology can adapt without always relying on a lens. That’s a great technical challenge.