INPUTItem、功能与场景
边界、架构、运行场景、接口与假设
PROCESS专业判断与独立评审
HARA、ASIL、安全目标、需求与确认措施
OUTPUT受控功能安全对象
版本、追溯、评审记录和交付基线
STATUS按项目配置
不以通用页面暗示所有能力均已标准化交付
HARA TO EVIDENCE
六个阶段，共享上下文，不共享草率结论。
COMPASS 组织对象、版本和流程；S/E/C、ASIL 及接受条件等专业判断仍由具备职责和能力的人员完成并批准。
- 01
Item 与功能边界
定义功能、接口、运行条件、架构与假设。
- 02
场景与危害事件
连接失效行为、运行场景、后果与受影响对象。
- 03
S / E / C 与 ASIL
记录参数判断、理由、分歧处理与最终结论。
- 04
安全目标
从危害事件形成目标，并保留来源与分配关系。
- 05
FSR / TSR 分解
把需求分配到系统、组件与责任角色。
- 06
验证与变更影响
连接验证证据；上游变化触发影响复核。
CONTROLLED OBJECTS
比“填完一张 HARA 表”更重要的，是对象之间没有断点。
同一个 Item 修订贯穿危害事件、ASIL、安全目标、需求和验证。导出是阶段性交付；受控对象关系继续服务于变更分析和后续确认。
- Item@修订定义上下文
- 危害事件引用场景与后果
- ASIL 结论记录参数与理由
- 安全目标追溯危害来源
- 需求与证据验证并冻结基线
INDEPENDENCE & CHANGE
让独立性和变更影响成为系统行为。
流程可以要求作者不能完成自己的批准；证据绑定具体对象修订，上游变化后相关确认结果进入待复核状态。
- 职责分离
- 作者、评审者和批准者按项目规则配置
- 判断留痕
- 记录结论、依据、修改与批准理由
- 影响分析
- 从 Item、场景或架构变化追到目标与需求
- 交付基线
- 冻结可复核的对象版本和引用关系
在开始前确认能力，不在官网上制造“全都可用”的错觉。
评估将逐项确认下列阶段的模板、字段、导入导出、审批和集成范围，并形成双方认可的成功标准。
HARA危害分析与风险评估
场景、危害事件、S/E/C、ASIL 与评审
GOALS安全目标与分配
来源追溯、责任对象、版本与批准
REQ需求分解与追溯
FSR / TSR、系统对象、双向关系与变更影响
EVIDENCE验证与交付准备
验证证据、确认措施、完备性与基线