一、行业挑战与适用场景
1.1 行业挑战
随着工业、轨道交通和汽车领域持续向智能化与高安全等级方向演进，嵌入式系统对运行平台的诉求已不再局限于"实时、稳定、能跑通"。典型挑战包括：
1.故障跨应用扩散：文件系统、网络协议栈、第三方中间件等复杂组件一旦出现异常，可能直接影响安全相关控制功能；
2.时间行为不可分析：周期性任务的触发节拍、单次执行时长和超时约束由各任务分散管理，难以满足功能安全对确定性的要求；
3.异常后行为不可控：内存访问异常、任务阻塞、时间监督失效等发生后，系统缺少受控的降级、停机或恢复路径；
4.认证与可维护性矛盾：既需要满足功能安全认证对开发流程和软件机制的严格要求，又需要保留对既有 RT-Thread 应用生态的兼容与可维护性。
1.2 适用场景
RT-Thread Safety 适用于对功能安全等级、可控性和可分析性有明确要求的嵌入式场景，主要包括：
1.工业控制：PLC、运动控制器、安全仪表系统（SIS）、工业机器人控制器等；
2.轨道交通：车载控制器、信号系统执行单元、轨旁设备等；
3.车载电子：ECU、VCU、区域控制器以及对安全等级有要求的车内功能模块；
4.其他对软件错误传播范围有明确约束的高安全相关场景。
二、产品定位与目标读者
2.1 产品定位
RT-Thread Safety 定位为面向功能安全场景的实时操作系统基础平台。它并非对 RT-Thread 实时操作系统的简单改写，而是在兼容 RT-Thread API 体系的前提下，围绕功能安全需求重新实现关键机制，并以产品级安全认证与安全生命周期管理为支撑，为安全相关软件提供可受控、可约束、可分析的运行底座。
2.2 目标读者
1.系统架构师与平台选型决策者：评估 RT-Thread Safety 是否匹配项目安全目标、认证路径与生态兼容性；
2.功能安全经理与认证审计方：理解产品覆盖的安全标准范围、研发流程约束与软件机制；
3.平台与驱动开发工程师：理解时间编排、osa 应用边界等扩展能力的运行模型，为上层应用和系统集成提供基础。
三、核心能力与相对 RT-Thread 的差异
3.1 传统实时操作系统能力
RT-Thread Safety 在兼容 RT-Thread 实时操作系统 API 的基础上，保留并增强了实时控制场景所需的内核能力：
1.多线程的创建、切换、运行状态管理以及调度控制；
2.基于优先级的可抢占式实时调度；
3.多线程间的同步与互斥机制：spinlock、semaphore、mutex；
4.多线程间的通信机制：event、mailbox、message queue；
5.中断管理及中断上下文与线程上下文的协同处理；
6.定时器管理与时间触发基础能力；
7.轻量级设备 I/O 模型，便于驱动框架与上层应用集成；
8.静态内存池管理，以满足资源使用可控、行为可预测的要求；
9.面向多核场景的资源保护与协同运行能力。
3.2 功能安全增强能力
3.3 支持的芯片架构
可支持 ARM Cortex-M、ARM Cortex-R 、RISC-V32 、Tricore（英飞凌半导体旗下）等国内外芯片架构，并随产品迭代持续扩展。
四、三大安全机制
围绕操作系统在功能安全中的职责，RT-Thread Safety 主要从隔离与访问控制、确定性执行与时间监督、故障响应与安全状态控制三个方面展开。与程序完整性检测、可信启动以及运行时软硬件协同安全检测相关的能力，主要由平台级安全机制承担；通信数据完整性、时序一致性及防重放保护则由独立的 E2E 保护机制实现。
4.1 隔离与访问控制
隔离与访问控制的核心目标，是防止非预期访问、资源误用以及故障在不同软件单元之间传播。RT-Thread Safety 通过内存分区、内核态与用户态分离、对象归属管理等机制，对任务、应用以及内核资源建立清晰边界。操作系统负责配置和维护这些边界，并结合底层内存保护单元（ARM 上的 MPU、RISC-V 上的 PMP），限制不同应用对代码区、数据区、栈空间以及内核对象的访问权限。
运行在用户态的程序无法直接修改系统级访问权限，也无法越界访问不属于自身的内存和对象。当单个应用发生异常时，故障会被限制在对应的软件边界之内，以避免向其他应用或整个系统直接扩散。
4.2 确定性执行与时间监督
时间监督的核心目标，是确保安全相关任务按预期时序执行，并在出现超时、阻塞、失活或执行节拍异常时及时发现。RT-Thread Safety 在基于优先级的可抢占式实时调度基础上，进一步关注周期性任务的触发、单次执行时长、周期频率以及关键资源占用时长等时间属性。
对于需要时间可分析性的场景，系统提供独立的周期性任务编排机制，由底层定时源按既定节拍触发任务或函数执行。时间监督逻辑则对任务的启动时刻、完成时限和周期一致性进行检查，为安全相关功能提供可预测的执行基础。
4.3 故障响应与安全状态控制
当系统检测到失效状态（例如内存访问异常、指令或数据异常、时间监督异常以及关键服务失效等）时，RT-Thread Safety 不会继续以未受控方式运行，而是按照预定义策略进入保护状态。系统会保留必要的故障上下文，并切换到受控的故障处理流程，由用户配置的安全策略决定后续动作：受控降级、受控停机或受控恢复。
这一机制的目的并非仅是报告故障，而是在故障发生后仍然保持系统行为可预期、可控制，使系统能够进入并维持预定义的安全状态。
五、扩展能力
为支撑上述安全机制，RT-Thread Safety 在传统实时操作系统能力之外，进一步引入了面向应用的资源抽象（osa）和面向周期任务的时间编排能力。
5.1 os application 应用
osa（os application）是 RT-Thread Safety 中引入的一种面向应用的资源容器抽象。它将一组相互协同的线程、资源和服务能力组织为一个独立的软件运行单元，并以此作为资源分配、权限控制和故障约束的基本粒度。
每个 osa 拥有清晰的资源边界，典型包括：
1.独立的代码区、数据区、栈空间以及可访问的内存地址范围；
2.一个或多个执行线程，以及与之关联的调度和运行上下文；
3.属于该 osa 的信号量、互斥锁、事件、邮箱、消息队列、定时器等内核对象；
4.面向该 osa 的设备访问权限和受控系统服务；
5.为该 osa 单独配置的内存池及其动态内存堆。
基于 osa 边界，系统可以在应用粒度上管理对象归属与访问关系：未经授权的线程或应用不能随意访问其他 osa 所拥有的内存区域、对象或服务资源。同时，osa 层级可配置独立内存池与专属动态堆，将动态内存风险限制在应用边界之内，便于容量规划、配额控制以及故障后的定向回收、局部重启或受控降级。
文件系统、TCP/IP 网络协议栈等复杂软件组件可被放入独立的 osa 中运行，与安全控制应用形成明确隔离。当这类组件发生异常时，操作系统可在 osa 粒度上识别问题来源，并将影响限制在对应应用边界内。
5.2 时间编排
时间编排用于在操作系统内部组织周期性任务和时间触发动作，使安全相关功能的执行节拍、触发关系和监督依据能够在统一框架下管理。
时间编排面向周期性任务的执行组织，而非定时器回调的简单封装。系统可将需要按固定节拍运行的任务、线程或处理函数纳入统一的编排关系中，在同一时基下描述其周期、相位偏移、触发时机、触发对象以及执行时限等约束。
通过时间编排，操作系统在统一时基下组织周期任务的释放与执行，可减少分散软件定时器带来的节拍漂移、触发关系不清晰和行为不一致问题，并为时间监督和异常处理提供明确依据。系统可基于该机制针对周期性任务持续监控：周期频率是否符合设定、单次执行时长是否超限、是否出现迟到 / 漏触发 / 连续超时，以及节拍一致性是否受到阻塞或异常负载影响。
时间编排与时间监督相互配合：编排给出计划触发点与节拍，监督基于这些计划信息对实际执行进行检查。这也是安全相关任务实现确定性执行的重要基础。
六、认证与合规
RT-Thread Safety 的开发遵循功能安全产品所要求的 V 字型开发流程，并具备产品级的功能安全认证。系统在产品层面可支持：
1.IEC 61508 SIL3：工业过程控制与安全仪表系统；
2.EN 50128 SIL4：轨道交通信号与车载控制相关应用；
3.ISO 26262 ASIL D：汽车功能安全相关电子电气系统。
具体认证范围、适用芯片平台、安全机制覆盖项、安全手册（Safety Manual）内容以及版本对应关系，请参见随产品发布的《安全手册》及相关认证文件。
七、配套工具与开发生态
为支撑安全相关软件的开发、调试与分析，RT-Thread Safety 提供由日志、交互命令、栈回溯与运行数据采集组成的调试工具体系：
1.ulog：轻量级运行日志，支持 LOG_E/W/I/D 等多级输出，便于记录关键事件、状态变化和异常信息；
2.msh：源自 RT-Thread 的 shell 交互环境，可用于执行命令、查看系统状态、辅助问题定位；
3.backtrace：面向 ARM Cortex-M/R 与 RISC-V32 等架构提供函数调用栈回溯能力，便于在异常场景下分析调用路径；
4.perf：用于采集系统运行数据并进行可视化展示，从时间行为、资源使用和整体运行状态等角度分析系统表现。
评论区
登录后即可参与讨论
立即登录