Taiwan's Only MIT Beacon Built to Fire-Service Specifications — Hardware to App, All Built In-House

“How many people went in? Who hasn’t come out yet? How much air is left in their tank?”

At a disaster scene, these questions are critical — yet the answers were never available in real time. Responders enter through smoke and chaos, and the commander outside can barely keep track of what’s happening inside — which battalion, which squad, how many groups, who’s assigned to which part of the fire. Personnel tracking is both the most important and the hardest thing to pin down at a disaster scene.

Through a multi-party collaboration, we took on this project with a single core mission: let the commander know, in real time, the status of every single responder inside a chaotic disaster scene.

---

The first major decision: build the hardware ourselves

Off-the-shelf personnel-tracking devices exist on the market, but none of them fully matched the demands of a firefighting scenario.

A firefighter’s working environment is extreme — high heat, thick smoke, water spray, dust — and personnel entering the scene are often wearing bulky gear, with no spare capacity to operate any extra equipment. After evaluation, we reached one conclusion: we had to build a custom Beacon device from the ground up — no commercial product could be retrofitted to solve this.

That decision raised the project’s difficulty considerably, but it also meant the final product genuinely fit the use case, instead of forcing firefighters to adapt their workflow around a device’s limitations.

---

The core system: Beacon + App + Back office

Custom Beacon hardware Every firefighter carries a BLE (Bluetooth Low Energy) beacon that continuously broadcasts an identity signal, letting the on-scene commander see “this person is here” from a tablet.

Hardware development covered:

• Form design (teardrop shape with glow-in-the-dark coating for identification in the dark)
• Mechanical design and mold tooling (hook-and-loop mounting compatible with firefighting gear)
• UV-printed identification graphics
• BLE firmware development (multiple iterations, culminating in the final production version)
• Obtaining NCC low-power radio-frequency device certification
• Passing IP67 water/dust resistance testing

A front-end app operable from a single tablet, dynamically showing entry timers and air-tank levels In a situation where every second counts, the information in front of the commander absolutely has to be clear, legible, and easy to control.

• On-scene personnel tracking: once on scene, the tablet continuously reads beacon signals, displaying key information like rank and air-tank level, tracking personnel arrival status in real time
• Visual drag-and-drop grouping: a carefully designed grouping workflow, intuitive and convenient, visually representing movement through the stages 【individual → group → standby → fire scene】, matching how commanders naturally operate

A back office with detailed historical records The back office is used by command-center staff, with features including:

• Detailed case logs, including when each person entered/exited and remaining air-tank levels — a key reference for post-incident reports
• Personnel roster management (cross-referencing battalions, squads, and abbreviations nationwide)
• Real-time on-scene tracking dashboard
• Historical record lookup and report export
• Account permission management (ranked by seniority/rank)

---

Challenges during development

BLE signal stability in a disaster environment

Beacons run stably in a lab environment, but a real disaster scene is far more complex: reinforced concrete blocking signals, water-spray interference, and dense clusters of moving firefighters all affect signal quality.

We spent extensive time with our beacon manufacturer, ENDEX AUTOMATION TECHNOLOGY CO., LTD., testing across a range of simulated environments — tuning the beacon’s broadcast frequency, receiver placement, and signal thresholds to find a parameter combination that runs reliably under real-world conditions. There was no shortcut through this process — only testing, again and again.

The physical assembly of the beacon itself was also a constant focus for improvement, including ultrasonic sealing methods and screw-mounting positions — every detail was scrutinized on this device measuring less than 4 square centimeters.

The strict demands of NCC certification

For self-manufactured hardware to be legally used in Taiwan, it has to pass NCC low-power radio-frequency device certification. The certification process comes with strict specification requirements and test items, and preparing documentation and submitting for testing took up a considerable amount of time. Any adjustment that fell out of spec could mean resubmitting from scratch, making schedule control a major challenge.

Integrating with the 119 dispatch API

The system needed to exchange data with the 119 dispatch system operated by the National Fire Agency, Ministry of the Interior to keep case data in sync. Confirming the government system’s API format required multiple rounds of communication and formal written correspondence, and the official stress test came with strict pass criteria.

Any delay at any stage could affect the entire system’s acceptance timeline.

The challenge of long-term operations

This project taught us: for a public-safety system, half the challenge is in development — and the other half is in ongoing operations.

The iOS app needs to be re-signed every few years as Apple updates its policies; the beacon firmware needs continuous updates to handle hardware aging; vulnerability scanning is a fixed annual audit requirement; and equipment wear requires spare-parts management and replenishment purchasing.

As the service expanded to other counties/cities, differences in hardware — tablets, in-vehicle terminal integration, and so on — across different fire departments brought their own set of system-change challenges. This work looks unrelated to “development” on the surface, but it’s exactly the kind of detail a professional team has to account for when it affects a system’s long-term operations.

---

Over five years of continuous support

From the system’s launch in 2020 through ongoing maintenance in 2026, Estab-Zenith’s services have covered:

• Continuous firmware updates (addressing hardware aging and new requirements)
• Periodic app re-packaging and re-signing (iOS/Android certificate renewal)
• Vulnerability scanning (supporting the agency’s information-security audits)
• Annual audit documentation and follow-up materials
• Beacon spare-parts replacement and new procurement
• Regular database backups and system log review

---

Project milestones

A system this complex, developed and launched within a single year!

Time	Milestone
March 2020	Project kickoff, requirements gathering completed
May–June 2020	Beacon hardware finalized, API format confirmed
November 2020	System public testing, stress testing, beacon mass production
December 2020	NCC certification obtained, formal acceptance
2021	Additional feature development
2022	Information-security audit, feature expansion
2023	Additional beacon procurement, certificate renewal
2026	iOS app updated to Swift

---

The core lesson from this project

A disaster scene tolerates neither system failure nor inaccurate data.

But our bigger takeaway is this: a system’s “completion” on the day of final acceptance is only the beginning — the real value lies in every subsequent deployment being used correctly.

Every certificate renewal, every audit requirement, every spare-part replacement is a continued commitment to “what we built actually works.” That sense of responsibility is the fundamental difference between a public-safety system and a typical commercial application.