Emergency Response Platform 104

Services/Emergency Response Platform 104

Emergency Response Platform 104

“Tryzub” — an integrated solution for emergency gas dispatching (104)

Tryzub is based on the universal Irish platform Phoenix-ESS and provides integration with the industrial telecommunications system CallWay — a single channel for receiving and routing all calls to 104. The solution is tailored to the specifics of the gas industry: it combines data from GIS and SCADA, coordinates teams and interdepartmental interaction, and ensures the security and auditing of all operations. The system is designed to eliminate emergency situations — from localizing household leaks to coordinating large-scale work on main pipelines. Thanks to its microservice architecture, Tryzub is easily scalable and can operate in the cloud or in a secure local circuit, ensuring uninterrupted service even during peak loads. Below is a brief description of the key features and technologies used to increase response speed, reduce risks, and simplify the operational work of dispatchers and field crews.

Main modules of the Tryzub platform
(Phoenix-ESS customization)
CALL INTEGRATION AND ROUTING MODULE (INTEGRATION WITH CALLWAY) — THE MAIN COMMUNICATION GATEWAY FOR 104

The CallWay integration module is the central gateway for incoming communications for the single number 104. It receives all citizen requests and automatic signals (phone calls, SMS, IVR, mobile applications, incoming messenger messages), converting them into standardized incidents in the Tryzub system. When a call comes in, the module automatically records the call metadata (subscriber number, time, direction, CDR), saves the voice recording, and transmits the stream decryption (ASR) for quick extraction of keywords (e.g., “leak,” “smell of gas,” “explosion”). If geo-information is available, it is picked up from CallWay (CLI/ANI, GPS from the mobile app) or calculated via triangulation/Cell-ID; if the coordinates are incorrect, the module launches a refinement algorithm: it sends an SMS/USSD with a quick questionnaire, initiates a callback, or asks the user to share their location via the mobile app.

Routing is performed according to pre-configured response rules for 104: by the danger of the event (high pressure leak vs. domestic leak), by area of responsibility (network sector, trunk/distribution), by the availability of data on the gas pipeline at the site of the event, and by the availability of crews. The module can simultaneously notify multiple recipients—the emergency team, the nearest duty station, the fire department, and the police—and generate a single incident card with action priorities. Built-in escalation scenarios automatically escalate the event to a senior dispatcher if parameters deteriorate (increase in the number of complaints about odors, confirmed by IoT sensors, or increase in CO/CH₄).

The CallWay module provides a convenient interface for the 104 operator: the call card shows the source, a recording of the conversation, a transcript, the estimated danger radius, suggested resources, and the nearest shut-off points/valves. It supports conference call functions (operator ↔ team ↔ 112 service/police), TTS notifications for mass alerts, sending messages to citizens (SMS/Push) with safety instructions and the ability to track responses. For auditing and service quality, the module maintains SLAs for response time, stores CDRs, and integrates with analytics to identify “false” and “repeat” calls. In terms of security, all traffic is encrypted, voice recordings and personal data are stored with role-based access control and retention policies required for regulatory compliance.

Thus, integration with CallWay transforms chaotic inputs into a manageable flow of information—calls and messages are automatically classified, geotagged, and routed as incidents with clear instructions for action for the field team and dispatcher.

INTEGRATION WITH GIS (ARCGIS) AND VISUALIZATION OF GAS FACILITIES ON GOOGLE MAPS

The Tryzub GIS module receives spatial and attribute data about the gas infrastructure from the central corporate GIS repository (ArcGIS) and projects this data onto Google Maps for the convenience of dispatchers and field crews.

Technically, data is transferred via secure connections to the ArcGIS REST API (token/SSO authentication) or via GeoJSON/Vector Tiles export. Tryzub automatically converts the received layers into a format suitable for overlaying on Google Maps.

Features important for the work of 104:

  • When the status of an object in ArcGIS changes (for example, “taken out of service for repair”), the layer automatically changes color and the availability of actions on Google Maps;
  • The route calculation for the team takes into account not only the Google road network (Directions API), but also the “internal” topology of the gas pipeline network: time to the nearest shut-off valve, passability for equipment, access restrictions to control points;
  • Mobile applications receive simplified vector packages (MBTiles) for offline maps with the latest synchronization from ArcGIS so that the team can see current objects even without coverage.

Overall, this approach provides a combination of ArcGIS as a source of reliable and manageable GIS data and Google Maps as an understandable and scalable visual backdrop for the dispatcher’s operational work and easy access to the necessary geoinformation for field teams.

REAL-TIME RESOURCE MONITORING AND MANAGEMENT

The module displays a compact overview of the readiness of teams and resources: current geolocation and status (en route/on site), ETA taking into account traffic, roles and qualifications of participants (gas specialist, welder, etc.) and certificate validity. Equipment and inventory are shown as separate objects with attributes — type (car with compressor, emergency van), remaining critical supplies (cylinders, sealants), fuel level, and calibration dates for instruments/PPE.

For shut-off valves, the module receives telemetry (position, pressure, drive status) and displays the availability and serviceability of units in real time; in case of anomalies, automatic alerts and recommended actions (notify repair, emergency shutdown) are generated. The mobile app offers quick actions: arrival check-in, photo sending, and QR inventory scanning. All critical device control operations are authenticated and logged for auditing.

INCIDENT MANAGEMENT MODULE

The central incident card is a compact but comprehensive working document for the dispatcher and the team. It records the type of incident (leak, odor, damage to the route, etc.), an automatic risk assessment, and the GIS-calculated impact zone (polygon with risk gradation and estimated evacuation zone). The card shows a list of assigned and reserve teams with their ETA, assigned roles and responsible persons, as well as the status of completion by stages (accepted, departure, on site, localized, closed).

The action log section sequentially records all steps: call entry time, communications (calls/messages via CallWay), orders sent, commands executed (valve closure, gas analyzer measurements), and system events; each entry contains a performer mark and a time stamp. Attachments — photos, videos, audio recordings of conversations, gas analyzer data — are stored next to the corresponding entries.

The card is linked to checklists for Regulation 104 (point bypass, safety measures, public notifications), as well as interdepartmental scenarios (automatic generation of tasks for firefighters/police in case of critical risk). The completion and closure of an incident require the signature of the person in charge and generate an immutable audit trail for reporting and subsequent analysis.

TRANSFER OF INCIDENT STATUS DATA

The incident card is automatically sent to the mobile application of the assigned team in a structured form: a brief summary, risk level with gas concentration thresholds (with specific values), PPE recommendations (filter/coverall type, breathing apparatus requirements), coordinates and route to the nearest shut-off valve (including distance and time to the point), and dispatcher contact with quick actions (“call,” “request backup,” “initiate shutdown”). Field staff can mark the status of stages (arrived → inspection → localization → closed), send photos/videos, upload gas analyzer readings, and attach measurement reports — all sent data is instantly synchronized with the card and marked with the time, author, and GPS coordinates.

The system verifies the readings received (compares them with thresholds and historical data), generates automatic prompts (e.g., “dangerous concentration — call the fire department and police”) and generates accompanying documentation (departure report, photo report). The mobile app supports offline mode: data is cached locally and synchronized when the network is restored, and all edits and commands are logged for subsequent audit and reporting.

SUPPORT FOR INTER-SERVICE INTERACTION

The platform enables the creation of joint response scenarios (composite workflows for gas + fire + police), where roles, control points, and PPE requirements are assigned to each service. When an escalation criterion is triggered, the card automatically sends structured notifications (with incident data, risk areas, and recommended measures) to the target systems of partners or to the 112/fire/police integration points. Notifications contain pre-set templates and priorities to avoid ambiguities.

Joint communication channels are available for operational coordination: secure conferences, group chats, and shared temporary access to the incident card (transfer of rights with recording of all actions). Each interagency task is linked to checkpoints and deadlines — the system tracks the status of completion, automatically reminds those responsible, and records deviations from the SLA for subsequent analysis and optimization of interaction.

ADAPTIVE MOBILE APPLICATIONS FOR TEAMS

The offline-first application ensures operation in poor connectivity conditions: maps (MBTiles), the latest network layers, and a register of shut-off valves, checklists, and instructions for regulation 104 are stored on the device. Field operators can quickly send photos/videos, attach measurement reports, and synchronize data when connectivity is restored — all with GPS tracking and time stamps. Integration with portable gas analyzers via BLE is supported — readings are automatically pulled into the incident card; Quick actions are also implemented for receiving commands: “initiate closure,” “request backup,” “mark location.” The application manages permissions: critical commands require confirmation from a supervisor and are recorded in the audit log.

INCIDENT STORAGE AND ANALYTICS

A centralized storage accumulates all calls, action logs, attachments, and telemetry into a coherent incident history. Based on this, reports are generated on response time, team workload, frequency, and locations of leaks; the data is available for dashboards and uploads for regulators. ML model support is implemented through a separate analytics layer: prepared samples and feature stores allow you to build forecasts of “hot spots,” assess the risk of equipment failure, and recommend preventive measures. Data storage and encryption policies comply with security regulations and retention requirements.

RESPONSE TEMPLATES AND SCENARIOS

A set of preconfigured scenarios covers typical accidents: domestic leaks, main leaks, damage during excavation work, mass poisoning, and explosion risk. Each scenario contains a sequence of actions, a list of necessary equipment and agencies involved, as well as configurable escalation thresholds (gas concentration, area of the site, number of calls). The scenarios dynamically adapt to conditions, taking into account wind direction, terrain, building density, and GIS data, automatically adjusting the evacuation zone and task priorities.

INTEGRATION WITH EXTERNAL DATABASES AND REGISTRIES

The system automatically synchronizes with land work registries, excavation permits, contractor lists, subscriber registries, and weather services (wind, temperature) via secure API/webhook channels. The data is used to verify calls (whether they are at the work site, etc.), alert contractors, and automatically block work in case of increased risk. Incoming data is validated and normalized, and discrepancies are flagged for manual review by the dispatcher.

New modules added to Tryzub
INSULATION POINT MANAGEMENT AND SHUT-OFF VALVE MAPPING

The centralized registry contains all physical and remotely controlled valves with attributes (ID, drive type, status, access restrictions, last check time). The map displays the nearest shut-off points to the incident location, calculates the time to complete isolation of the section (including the time for the crew to arrive and the time for the mechanical operation), and visualizes the list of subscribers/objects that will be de-energized during the shut-off. The module provides quick actions: step-by-step instructions on the shutdown sequence, initiation of remote shutdown (if permissions and telemetry are available), and formation of a plan to minimize the impact on critical infrastructure.

CONTROL OF EXCAVATION WORK AND INTEGRATION WITH CONTRACTORS

The platform receives data on issued excavation permits and earthworks plans and automatically compares them with the gas network map. When the work area intersects with a gas pipeline, the system generates warnings for the contractor and dispatcher, sends safety instructions, and, if necessary, blocks work approval until compliance with requirements is confirmed. A log of communications and inspections is maintained, with the ability to schedule an inspection visit and record the results in the work card.

MANAGEMENT OF EMERGENCY RESOURCES AND GAS EQUIPMENT INVENTORY

The inventory system tracks the availability of spare cylinders, emergency kits, PPE, and the condition of equipment (calibration, expiration dates). A set of minimum balances is determined for each emergency station; when the threshold is reached, a replenishment request is automatically created and a notification is sent to the responsible warehouse. A history of material usage by incident is recorded and integrated with the logistics service for fast delivery of kits to the site.

THIRD-PARTY REGISTRATION AND CONTRACTOR CONTROL

The contractor register contains the company profile, a list of permits, insurance policies, and work history. Before starting work, the system automatically checks the contractor’s compliance with safety requirements (availability of permits, calibrated tools, trained personnel) and generates instructions/conditions. All contractor visits and operations are logged: time, place, responsible persons, inspection results — this facilitates accountability and subsequent auditing.

CERTIFICATION AND PERSONNEL QUALIFICATION RECORDS

The module stores data on the qualifications and certificates of each employee (permit level, date of last retraining, certificate validity). When assigning tasks, the system automatically checks the compliance of competencies with the task requirements and blocks the assignment for untrained personnel, offering alternative candidates or requesting confirmation from the manager. Reminders about the need for retraining and the generation of reports on training and shift staffing are also implemented.

TECHNOLOGIES
THE TECHNOLOGICAL BASIS OF THE UNIVERSAL EMERGENCY PLATFORM

This system has been developed with strict requirements for reliability, fault tolerance, and round-the-clock availability (24/7/365) in mind. All of its components operate in high-readiness mode, with minimal delays in processing events, and ensure the continuous provision of emergency assistance. Thus, the technological architecture of the Emergency Platform combines the flexibility of microservices, the power of the .NET ecosystem, and the reliability of cloud technologies, while remaining adaptable for on-premise deployment in government structures.

ARCHITECTURAL PRINCIPLES
  • Microservice architecture — Each system function (call reception, dispatching, GIS service, resource management) is implemented as an isolated, highly specialized service. This makes it possible, for example, to scale the voice call processing service tenfold in the event of a mass incident without affecting the analytics module. Updates and fixes are made quickly and without completely shutting down the platform, which is critical for the work of emergency services.
  • API-first approach — All interactions between services within the platform and with external systems (e.g., the Ministry of Emergency Situations, hospitals, the Ministry of Internal Affairs) are built through clearly defined and documented APIs. This creates a “common language” for integration, allowing new services (such as emergency utility services) to easily connect to the platform using the same standard interfaces as emergency medical services.
  • Enterprise Service Bus — Acts as the “nervous system” of the platform. When a new call comes in, the event (with all the details) is published to the bus. It is instantly and asynchronously received by the dispatching service (to find an available crew), the GIS service (to build a route), the logging service (for recording), and analytics (for accounting). This ensures instant response and data consistency across all components.
  • Cloud-native design — The system is designed to work in modern cloud environments, providing unprecedented elasticity and fault tolerance. For example, in the event of a failure in one Azure data center, the platform automatically switches to a working one. At the same time, the ability to work in closed government circuits has been implemented, so the design allows for deployment on private Kubernetes clusters.
TECHNOLOGY STACK
  • Language and frameworks — C# and .NET 8+ were chosen for their performance, security, and rich ecosystem for building complex enterprise solutions. [ASP.NET](https://asp.net/) Core enables the creation of high-performance APIs, SignalR provides instant notification of new calls to all dispatchers, and modern front-end frameworks (Blazor/React/Angular) provide intuitive and responsive interfaces for operators in high-stress situations.
  • Microservices management — Kubernetes automates the deployment, scaling, and lifecycle management of hundreds of microservices. If a container with a routing service goes down, Kubernetes immediately restarts it. Service Mesh (e.g., Istio) provides secure and observable interaction between services, automatically encrypting traffic and providing detailed telemetry.

INTEGRATION AND DATA EXCHANGE

  • Messaging (RabbitMQ/Kafka) — Handles peak loads from thousands of IoT sensors or calls, ensuring that no event is lost. Kafka, with its message persistence capability, is ideal for replaying events for the purpose of analyzing past incidents.
  • API Gateway (Ocelot/YARP) — Acts as a single secure entry point to the platform for all clients (mobile apps for medical professionals, web interface for dispatchers). Routes requests to the appropriate microservices, authenticates and caches responses, reducing load.
  • Event sourcing and CQRS — For absolute reliability, data on critical actions (e.g., each dispatcher command, each change in crew status) is stored as a sequence of events. This allows the course of any incident to be accurately reconstructed and ensures data consistency.
  • Geographic information services — The core for resource coordination. Integration with different map providers (Google Maps for detail, OpenStreetMap for economy) and the use of powerful GIS servers (PostGIS) allow not only to display a map, but also to calculate optimal routes taking into account traffic jams, perform spatial analysis (find all teams within a 2 km radius), and visualize areas affected by emergencies.
  • Databases — Multilingual data storage: relational DBMS (SQL Server/PostgreSQL) for transactional data (accounts, call logs), specialized PostGIS — for geodata, Redis — for caching frequent queries (e.g., list of available crews) and sessions, and highly scalable storage (Elasticsearch) — for fast search through gigabytes of logs and analytics.
ENSURING SECURITY AND RELIABILITY
  • Authentication and authorization — Single Sign-On for all employees of different services through corporate Active Directory. Strict role-based access control (RBAC): a dispatcher can send a team, but cannot delete a call record, which is only available to the shift supervisor.
  • Encryption — All data transmitted between the control center, mobile medical applications, and databases
CI/CD AND LIFECYCLE MANAGEMENT
  • Build and testing — Any code change automatically goes through a rigorous build cycle and comprehensive testing (unit, integration, load tests) before entering the production environment. This ensures the stability and quality of each update.
  • Deployment — The process of deploying new versions of services is fully automated and managed through GitOps (ArgoCD) tools. The infrastructure is described by code (Infrastructure as Code), which makes it reproducible, versionable, and eliminates human error during manual deployment.
  • Updates without downtime — Blue-Green and Canary deployment strategies allow critical platform components to be updated without any interruption. The new version of the service is deployed in parallel with the old one, a small percentage of traffic is transferred to it for testing, and only after a successful test is the traffic switched over completely.