®01
指挥调度中心集成与报警受理
记录数据流和责任人的接口清单
了解更多
服务于您所在行业的从业者。
- 综合指挥调度中心
- 市政主管机构与联合事务机构
- 急救服务与救援组织
- 消防部门与民防机构
您的重点领域
理解任务。设计方案。
我们通过安全接口连接指挥调度系统、紧急呼叫受理、BOS 数字集群通信与外部数据源，在德国数据中心以冗余方式运行该平台，并对您的指挥调度中心进行加固以抵御外部攻击。
从战略到系统
六个服务模块
六大行动领域。您可以选择想要深入了解的方向。
01指挥调度中心集成与报警受理NG112 与 eCall · IVENA eHealth · Apache Kafka
我们的方法
一个指挥调度中心汇集了来自多家厂商系统的报警受理、指挥调度系统、警报通知、无线通信和地理数据。我们通过带版本管理接口的集成层将这些组件连接起来，通过 IVENA 接入医院收治能力等外部数据源，接入符合 NG112 标准并支持 eCall 的紧急呼叫，并在每个接口投入实际运行前对其进行负载测试。变更分阶段进行，以确保报警受理和警报通知持续正常运作。
服务范围详情
- 接口清单，记录指挥调度系统、无线通信、警报通知和地理数据之间的数据流、责任人和依赖关系
- 带中间件和事件处理机制的集成层，使各系统无需直接耦合即可交换出警数据
- 依据 NG112 标准（含 eCall）的报警受理，包括位置传输，以及接入德国报警应用 nora
- 通过 IVENA 接入医院收治能力信息，通过 OGC 服务接入地理数据和气象预警
- 为每个接口进行负载和故障测试，制定审批流程，并在出警高峰期之外分阶段上线
一家急救服务机构消除了指挥调度系统与医院对接之间的重复录入；来自 IVENA 的收治能力信息直接显示给调度员，每次交接都有记录。
02BOS 数字集群网络、警报通知与移动出警数据TETRA · POCSAG · Android 与 iOS
我们的方法
基于 TETRA 标准的 BOS 数字集群网络传输语音、状态消息和位置信息，警报通知通过寻呼机和应用程序送达救援人员。我们开发的应用程序将状态消息和位置信息从无线网络导入指挥调度系统，同时通过 POCSAG、TETRA 和应用程序并行触发警报通知，并在车载终端和平板电脑上向救援人员展示最新出警数据。这些应用在网络中断时仍能继续工作，并在连接恢复后自动同步数据。
服务范围详情
- 通过指挥调度中心接口接入 BOS 数字集群网络，依据 TETRA LIP 标准传输状态消息、短信和位置信息
- 警报通知服务，可通过 POCSAG 寻呼机、TETRA 和应用程序触发，并支持回执确认和升级机制
- 面向车辆和平板电脑的移动应用，支持离线运行，涵盖出警数据、导航和出警记录
- 基于设备证书和移动设备管理的角色与登录机制，并对设备上的数据进行加密
- 应用的运维，包括监测、在约定窗口内更新，并为指挥调度中心和救援人员提供支持
一支消防队用一项能同时触发寻呼机、TETRA 和应用程序的服务，取代原先通过无线电和电话名单分别进行的警报通知；回执直接显示在指挥调度系统中。
03高可用性与灾难恢复Kubernetes · PostgreSQL 搭配 Patroni · Veeam
我们的方法
高可用性意味着即使单个组件、某个站点或某个网络发生故障，报警受理和指挥调度系统仍能继续运行。我们规划具备异地冗余数据存储、自动化切换机制和经过测试的恢复方案的冗余站点，并在德国数据中心或您的指挥调度中心内运维该平台。恢复时间目标和数据丢失限值由我们依据 ISO 22301 与您共同确定，并定期进行演练。
服务范围详情
- 冗余方案，包含两个站点、独立的网络路径、备用电源，以及按系统划分的优先级
- 基于 PostgreSQL 和 Patroni 的异地冗余数据存储、跨站点 Kubernetes 集群，以及自动化切换
- 使用 Veeam 进行备份和恢复，采用不可篡改备份抵御勒索软件，并配备经过测试的恢复方案
- 依据 ISO 22301 的业务连续性管理，包括应急手册、备用方案，以及在真实负载下的演练
- 监测系统，向值班人员发送告警，并进行容量规划和在约定窗口内的维护
一个联合体的两个指挥调度中心互为备份；在一次演练中，第二站点接管报警受理，而第一站点则在不丢失数据的情况下重新启动。
04作为关键基础设施的指挥调度中心 IT 安全Microsoft Sentinel · Splunk · OPSWAT MetaDefender Kiosk
我们的方法
指挥调度中心是勒索和破坏活动的目标，KRITIS 和 NIS2 要求具备攻击检测、报告流程和定期证明材料。我们依据 BSI IT-Grundschutz 评估安全状况，对报警受理、行政管理和互联网之间的网络进行隔离，对系统进行加固，并部署针对指挥调度中心场景的 SIEM 系统。可移动存储介质在接入前会先经过检测，经过演练的事件响应流程确保遵守报告时限。
服务范围详情
- 依据 BSI IT-Grundschutz 进行安全评估，确定每个系统的保护需求，并列出按优先级排序的措施清单
- 通过防火墙对报警受理、指挥调度系统、行政管理和互联网出口进行网络隔离
- 使用 SIEM 进行安全监测，依据 KRITIS 运营方的要求进行攻击检测，并配备值班服务
- 使用 OPSWAT MetaDefender Kiosk 检测可移动存储介质，并配备终端防护和补丁管理流程
- 事件响应计划，包含依据 NIS2 的报告流程、演练，以及面向 BSI 和监管机构的证明材料
一家市政指挥调度中心建立了攻击检测和报告流程；向 BSI 提供的证明材料以 SIEM 日志、演练报告和更新后的风险分析为依据。
05面向出警数据的身份认证、加密与密钥托管Utimaco u.trust GP HSM · Thales Luna · Entrust nShield
我们的方法
出警数据和健康数据需要特别的保护，GDPR 和 KRITIS 要求加密、访问控制和日志记录。我们为调度员、车辆和设备搭建一套 PKI，将其密钥存放在 HSM 中，并使用来自该托管体系的密钥对数据库、备份和移动设备进行加密。调度员使用智能卡或 FIDO2 登录，管理员遵循双人复核原则，每一次密钥使用都会被记录。
服务范围详情
- 面向数据库、备份和设备的密码方案，包含密钥层级、角色划分，以及依据 BSI TR-02102 的算法规范
- PKI 的根 CA 离线保存，签发 CA 运行在 HSM 上，为调度员、车辆、平板电脑和服务签发证书
- 厂商中立的 HSM 选型与接入，例如 Utimaco u.trust GP HSM、Thales Luna 或 Entrust nShield
- 使用智能卡或 FIDO2 登录，为管理员提供特权访问管理，并记录每一次密钥使用
- 使用 Utimaco LAN Crypt 对文件和设备进行加密，密钥托管和恢复流程均有文档记录
一家急救服务机构使用来自 HSM 的密钥对出警记录和平板电脑进行加密；数据保护官获得密码方案、角色划分和日志证明材料。
06面向出警规划的数据平台与人工智能Apache Kafka · PostgreSQL 与 PostGIS · Apache Spark
我们的方法
多年积累的出警数据揭示了何时何地会发生哪些出警任务，以及车辆在途时间。我们将出警、车辆和地理数据汇总到一个数据平台中，在此基础上训练用于出警量预测和站点规划的模型，并为需求规划、质量管理和演练提供分析报告。个人数据会进行假名化处理，每个模型都依据欧盟《人工智能法案》编制文档并定期接受审查。
服务范围详情
- 数据平台接入指挥调度系统、车辆数据、地理数据和人口统计数据，数据存储在德国境内
- 按时间和空间分析出警量的模型、响应时限分析，以及站点方案模拟
- 面向需求规划、质量管理的分析报告，以及提交给主管机构和监管机构的报告
- 依据 GDPR 进行假名化处理、制定删除方案，并开展数据保护影响评估
- 模型运维，包括版本管理、数据质量监测，以及依据欧盟《人工智能法案》编制文档
一家主管机构基于多年出警数据模拟急救站的选址方案；需求规划因此依据可追溯的分析结果，而非凭经验估算。
典型项目场景
变革真正落地之处。
项目往往始于一个具体的挑战。以下示例将典型的现状、可能的解决思路和期望达成的结果结合在一起。
示例性现状说明，并非客户案例。
01 / 应急救援服务
一个指挥调度中心联合体的备用站点
两个指挥调度中心各自独立运作，备用站点从未在真实负载下测试过，恢复时间也没有明确规定。
解决方案
制定互为接管的冗余方案，实现异地冗余数据存储和自动化切换，编制依据 ISO 22301 的应急手册，并进行真实负载下的演练。
报警受理接管经过测试，恢复时间形成书面记录，演练记录提交给主管机构和监管机构。
02 / 应急救援服务
一家急救服务机构的接口整合
指挥调度系统、无线状态、警报通知和医院对接各自独立运行，调度员需要多次录入数据。
解决方案
编制接口清单，搭建带事件处理机制的集成层，接入 BOS 数字集群网络、IVENA 和警报通知，并对每个接口进行负载测试。
指挥调度系统中形成统一态势图，不再重复录入数据，接口具备版本管理和审批流程。
03 / 应急救援服务
一家市政指挥调度中心的 NIS2 落地实施
作为 NIS2 管辖实体的认定即将到来，风险分析、攻击检测和报告流程尚未建立。
解决方案
依据 BSI IT-Grundschutz 进行安全评估，实施网络隔离，部署带应用场景的 SIEM 系统，制定包含报告流程的事件响应计划，并开展演练。
形成可供证明的风险分析，攻击检测已投入运行，报告流程的时限也经过演练。
协作
清晰的路径。与您的团队同行。
从初步了解情况到日常运维：我们会共同商定各阶段的优先事项、职责分工和成果。
我们的工作方式
- 01
评估
系统全景、故障风险、保护需求，以及与 KRITIS 和 NIS2 相关的差距
按优先级排序的措施清单、接口清单、风险分析，以及针对 KRITIS 和 NIS2 的差距分析 - 02
方案
目标架构、冗余方案、安全措施、运维模式
目标架构、冗余与恢复方案、安全方案、运维模式 - 03
实施
在出警高峰期之外分阶段实施接口、冗余、安全和应用
集成后的系统、经过测试的切换机制、攻击检测能力，每个阶段都附有文档和验收 - 04
运维
监测、值班、演练、审计、知识转移
监测、在约定窗口内维护、演练记录、审计支持，以及分阶段移交
- 01
您希望改变什么？
当前面临的挑战，以及您期望达成的结果。
- 02
涉及哪些系统？
站点、应用和接口的概览。
- 03
有哪些约束条件？
项目时间安排、维护窗口和已知的依赖关系。
- 04
哪些人需要参与？
来自 IT、安全和运维部门的合适联系人。
背景与决策参考
什么是面向应急服务的 IT 解决方案？
六大行动领域，从指挥调度中心集成到面向出警规划的数据平台，均由 OTOKO® 规划、集成和运维。每一次变更都确保报警受理和警报通知持续正常运作。整套方案运行在德国数据中心。
面向应急服务的 IT 解决方案让报警受理、指挥调度系统和警报通知全天候保持可用，通过受保护的接口连接指挥调度中心、无线通信和救援人员，并向 BSI 和监管机构提供防护措施的证明。OTOKO® 为此覆盖六大行动领域：指挥调度中心集成与报警受理、BOS 数字集群网络与配合移动出警数据的警报通知、高可用性与灾难恢复、依据 KRITIS 和 NIS2 的 IT 安全防护、面向出警数据的身份认证与加密，以及面向出警规划的数据平台与人工智能。
与单纯的咨询项目的区别在于运维和证明材料。每个接口、每次切换和每次恢复都会生成记录、版本信息，以及 KRITIS、NIS2 和 BSI IT-Grundschutz 要求的资料。整套方案运行在德国数据中心，跨两个站点实现冗余，密钥掌握权始终留在您的指挥调度中心。
为什么选择 OTOKO® 服务应急领域
- 密码学与 HSM
密码学和硬件安全模块是我们的核心能力。因此，出警和健康数据的密钥、设备证书以及备份都存放在经过认证的硬件中。
- 德国数据中心
整套方案都运行在德国数据中心。从集成层到数据平台，均跨两个站点实现冗余。
- 关键基础设施（KRITIS）与受监管行业
我们与关键基础设施运营方和受监管行业合作。我们深知 BSI、监管机构、主管机构和数据保护官的要求。
- 同一团队负责到运维
同一个团队为您提供从咨询到运维的全程支持。集成开发人员、平台工程师和安全专家持续负责，不会移交给第三方。
框架条件与详情
指挥调度中心与急救服务项目启动前的典型现状
大多数指挥调度中心失败的原因不在于缺少技术，而在于孤立系统、未经测试的冗余，以及缺失面向监管机构和 BSI 的证明材料。
01
维护只能在运行中进行
由于报警受理从不间断，没有可用的维护窗口，对指挥调度系统的任何改动都存在中断报警受理的风险。
02
多家厂商的孤立系统
指挥调度系统、无线通信、警报通知、地理数据和医院对接来自不同的厂商，调度员不得不重复录入数据。
03
纸面上的冗余
备用站点确实存在，但切换从未在真实负载下演练过，恢复时间也没有任何明确规定。
04
缺少 KRITIS 和 NIS2 所需的证明材料
防护措施已经落实，却没有 BSI 和监管机构希望看到证明的风险分析、攻击检测和报告流程。
三种运维模式
| 本地部署 | 德国云 | 超大规模云服务商 | |
|---|---|---|---|
| 数据存储 | 您的指挥调度中心、您的数据中心、您的 HSM | 德国数据中心，两个站点，依据 ISO 27001 运营 | Azure、AWS 或 Google Cloud，德国区域，用于分析和演练 |
| 运维 | 您的团队，或由 OTOKO® 以托管服务形式运维 | OTOKO®，提供值班服务和约定的维护窗口 | 共同承担，平台服务由云服务商提供 |
| 工具 | 指挥调度系统、无线接入、PostgreSQL、本地部署的 Kubernetes | 托管集成层、异地冗余数据存储、HSM | 托管数据服务、分析、云端 HSM 服务 |
| 适用于 | 报警受理、指挥调度系统、无线接入 | 需要冗余保障和证明材料的指挥调度中心联合体 | 数据平台、模拟分析、培训 |
| 合规 | 完全掌控，证明材料来自您的 ISMS | 依据 GDPR 签订数据处理协议，数据位于德国，并提供 KRITIS 证明材料 | 数据处理协议、标准合同条款，不涉及报警数据 |
合作方式
项目
边界清晰的项目，例如接口整合或备用站点建设，具有明确的成果、里程碑和验收。
- 评估、方案、实施、移交
- 固定价格，或按里程碑以实际工作量计费
- 适用于系统更换、备用站点建设和证明材料准备
团队扩充
集成开发人员、平台工程师或安全专家加入您的团队，使用您的工具和审批流程，并配合指挥调度中心的排班安排。
- 熟悉您的工作流程、系统和出警规则
- 可随项目进展灵活调整规模
- 适用于拥有自有 IT 团队但人力不足的主管机构
托管服务
OTOKO® 运维集成层、平台或安全监测系统，提供约定的服务水平、全天候值班，以及 KRITIS 和 NIS2 要求的报告。
- 监测、值班、更新和支持
- 合同中约定报告、演练记录和证明材料
- 适用于没有自有平台或安全运维团队的指挥调度中心
标准与证明材料
指挥调度中心和急救服务领域各项规定的要求，以及 OTOKO® 为此提供的交付物。
| 标准项 | 要求 | OTOKO® 提供 |
|---|---|---|
| KRITIS | 适当的技术和组织防护措施、攻击检测系统、重大故障报告，以及向 BSI 定期提供的证明材料 | 包含具体措施的安全方案、配备攻击检测的 SIEM 系统、报告流程，以及证明所需的资料 |
| NIS2 | 风险管理、在规定时限内报告重大事件、供应链安全、业务连续性，以及管理层的责任 | 风险分析、带时限的报告流程、供应链审查、应急手册，以及面向管理层的资料 |
| GDPR | 合法依据、数据最小化原则、针对健康数据的加密和访问控制、数据处理协议，以及数据保护影响评估 | 密码方案、角色划分和日志记录、数据平台中的假名化处理、数据处理协议，以及协助完成影响评估 |
| ISO 22301 | 业务连续性管理，包括关键流程分析、恢复目标、应急预案和定期演练 | 冗余方案、明确的恢复目标、应急手册，以及带记录的真实负载演练 |
| BSI IT-Grundschutz | 保护需求评估、按模块建模、落实各项要求，并在安全方案中提供证明材料 | 针对每个系统的保护需求分析、基于 IT-Grundschutz 模块的安全方案、经过加固的系统，以及依据 IT-Grundschutz 的运维流程 |
常见问题
好问题。清晰的答案。
15 条解答，涵盖您的行业、项目以及后续运维。
行业与行动领域6 问题
OTOKO® 为应急服务提供哪些 IT 解决方案？
服务范围涵盖指挥调度中心集成（含报警受理、指挥调度系统和外部数据源）、BOS 数字集群网络与配合移动应用的警报通知接入、具备灾难恢复能力的高可用运行、依据 KRITIS 和 NIS2 的 IT 安全防护、面向出警数据的加密与 PKI，以及用于出警规划的数据平台。每个行动领域都可单独委托，也可整体委托，并可按需由 OTOKO® 负责运维。
在 IT 故障发生时，指挥调度中心如何保持运转能力？
当某个组件、站点或网络发生故障时，位于两个站点的冗余系统会自动接管，切换按经过测试的流程自动进行。备用方案，例如备用站点或预先准备好的手动流程，可在技术恢复之前维持报警受理正常运作。依据 ISO 22301 开展的演练会定期检验恢复时间和流程在真实事故中是否可靠。
OTOKO® 如何将 BOS 数字集群网络接入指挥调度系统？
我们通过 TETRA 网络的指挥调度中心接口，将车辆的状态消息、短信和位置信息导入指挥调度系统，并将出警指令回传。接入过程通过一个集成层完成，该集成层能够检测无线网络故障，并在连接恢复后自动同步数据。我们同时通过寻呼机、无线电和应用程序并行触发警报通知。
KRITIS 和 NIS2 对我们的指挥调度中心意味着什么？
KRITIS 要求具备技术和组织防护措施、攻击检测能力，并向 BSI 定期提供证明材料，NIS2 则进一步要求风险管理、重大事件的报告时限、供应链安全，以及管理层的责任。现状盘点会显示哪些差距需要优先弥补。我们与关键基础设施运营方和受监管行业合作，这种做法在那里是标准流程。
患者的健康数据如何得到保护？
健康数据会在数据库、备份和移动设备上使用来自 HSM 的密钥进行加密，访问通过角色权限和智能卡或 FIDO2 完成，每一次密钥使用都会被记录。在数据平台中，模型使用经过假名化处理的数据进行运算。密码方案、角色划分和日志记录共同构成面向数据保护官的证明材料。
如何在不中断出警运作的情况下进行变更？
每次变更都会先在包含指挥调度中心接口的测试环境中进行验证，随后在出警高峰期之外分阶段引入，并配备回退方案。冗余系统使我们能够在更新一个站点的同时，由另一个站点承担报警受理任务。维护窗口、升级路径和审批我们都会与指挥调度中心管理层协调确定。
启动与实施5 问题
我们可以从单一行动领域开始吗？
可以。我们可以先界定一项具体任务，同时关注它与其余基础设施之间的接口，并在实施前明确哪些服务属于委托范围。
我们应该为初步沟通准备什么？
起步时，只需简要说明面临的挑战、涉及的系统以及您期望达成的结果即可。已知的时间节点和合适的联系人也会有所帮助。访问凭证或机密的系统文档不应包含在首次咨询中。
谁应该参与该项目？
安全架构师: 目标架构、安全方案、KRITIS 和 NIS2 证明材料. 集成开发人员: 接口、中间件、无线通信与警报通知接入. 平台工程师: 冗余平台、切换、恢复. 密码学专家: PKI、HSM、出警数据加密. 数据工程师: 数据平台、模型、分析报告. 项目负责人: 里程碑、验收、报告.
时间计划和工作量是如何确定的？
我们会综合考察系统、接口、文档现状和运维方面的约束条件。经过协商确定的范围和里程碑，构成工作量评估的基础。缺少这些信息而给出的固定工期是不可靠的。
项目第一阶段会交付什么？
系统全景、故障风险、保护需求，以及与 KRITIS 和 NIS2 相关的差距 按优先级排序的措施清单、接口清单、风险分析，以及针对 KRITIS 和 NIS2 的差距分析
运维与持续完善4 问题
有哪些可能的合作方式？
项目: 边界清晰的项目，例如接口整合或备用站点建设，具有明确的成果、里程碑和验收。 团队扩充: 集成开发人员、平台工程师或安全专家加入您的团队，使用您的工具和审批流程，并配合指挥调度中心的排班安排。 托管服务: OTOKO® 运维集成层、平台或安全监测系统，提供约定的服务水平、全天候值班，以及 KRITIS 和 NIS2 要求的报告。
如何完成向运维的移交？
监测、值班、演练、审计、知识转移 监测、在约定窗口内维护、演练记录、审计支持，以及分阶段移交
我们之后可以再补充其他站点或系统吗？
这一点可以在最初的方案中予以考虑。有文档记录的接口和可复用的规则，为后续扩展打下基础。不过，每新增一个站点或系统，仍会针对其特殊需求单独进行评估。
该方案如何保持长期可运维？
职责分工、周期性任务和变更流程，会与技术实施一并确定。文档记录和知识转移有助于您的团队开展日常工作。具体包含哪些工作内容和持续支持，会在服务范围中明确约定。
应急救援服务
让我们一起探讨下一步。
让我们探讨如何以高可靠性整合您的指挥调度中心，并将其作为关键基础设施加以保护。
预约初步沟通
