摘要：现代汽车的电气架构复杂度逐年攀升，这一趋势源于客户需求对应的功能迭代。而当前最新的需求——动态驾驶任务的自动化，势必带来汽车行业有史以来最重大的变革。自动驾驶所需的功能不仅大幅提升了系统复杂度，还彻底移除了人类驾驶员这一兜底角色（以往驾驶员通常负责事后处理意外故障）。因此，架构设计需要比以往更严谨的规范，才能维持汽车行业一贯的安全水准。
本文章的研究工作依托瑞典创新局Vinnova资助的FFI项目ARCHER，与工业合作伙伴斯堪尼亚商用车公司紧密合作开展。文章旨在结合工业实践与安全标准（如ISO 26262）的核心原则，提出一套适用于研发概念阶段的架构设计方法。
文章的核心贡献分为两大部分：
A部分：①分析自动驾驶架构设计的核心挑战，为文章后续研究提供研究动机；
B部分：②依据ISO 42010标准定义功能安全视角；③提出一套系统化提取传统组件信息的方法；④构建一套在不确定性场景下，基于传统系统信息开展架构设计的流程，最终输出ISO 26262标准要求的工作产物——初步架构假设（PAA）。
“B部分”的研究成果共同构成了一套完整的初步架构假设设计方法。
工业界开展研究的一大难点，是在理想原则与实际应用之间找到平衡。斯堪尼亚公司各部门均验证了“B部分”提出的方法具备实用价值，文章还与资深架构师合作开展了多项案例研究，评估方法的有效性。结果表明，该方法既能生成符合企业质量要求的初步架构假设，还能发现以往非系统化设计方法未察觉的架构缺陷。基于上述优势，斯堪尼亚已委托开发支撑该方法的原型工具，并将其应用于自动驾驶相关项目。后续将结合项目落地经验持续优化这套方法。
本研究的另一项成果，是基于“B部分”案例研究形成了两项专利申请。这些专利源于方法应用过程中发现的实际需求，提出了融合安全策略的参考架构未来研究方向，可在可检测故障与失效场景下保障系统安全。为验证该构想，研究团队已启动自动驾驶关键场景及其要素的识别工作，瑞典皇家理工学院也正在设计开发一套灵活的仿真平台，用于测试选定的关键场景。
原文作者：Naveen Mohan
原文标题：Architecting Safe Automated Driving with Legacy Platforms
编译：猿东东，猿西西
通俗意义上的自动驾驶（即动态驾驶任务的实际自动化）概念已存在多年。早在20世纪60年代，就有未来汽车自主行驶、驾驶员转变为乘客并利用时间开展高效工作的构想。90年代中期，卡内基梅隆大学的研究人员宣称完成了超6000英里的自动驾驶里程，德国联邦国防军慕尼黑大学的研究团队也提出了类似成果。但随着任务复杂度的真实面貌逐渐显现，这些构想大多淡出视野，自动驾驶一度看似遥不可及。
尽管此前已有多次自动驾驶研发尝试，但近期技术突破的核心原因是传感技术与算力的提升，使得实时机器推理算法得以开发。学术界与工业界虽展示了多款自动驾驶原型车。
要实现盈利性批量生产目标，自动驾驶功能必须集成到当前整车制造商使用的复杂车辆架构中。现代车辆架构与数十年前的架构截然不同——早期车辆仅有少数电子控制部件，而如今这些独立控制的嵌入式系统已演变为大规模互联分布式系统，一台现代车辆可搭载超100个独立电控单元，提供近300项用户价值功能。
在成本敏感的汽车行业，将这些功能、硬件与软件组件整合为结构化产品线（即可复用组件平台），进一步提升了系统复杂度。
基于平台的研发模式、成本控制、功能安全及其对重型商用车自动驾驶架构设计的影响，是瑞典国家研究项目ARCHER（Vinnova-FFI资助）的核心驱动因素。ARCHER项目由瑞典皇家理工学院与斯堪尼亚商用车公司联合开展，为本研究提供主要资金支持。项目目标如下：
项目总体目标：研发方法、原则与参考系统架构，实现安全、可靠、高性价比的全自动驾驶重型车辆。研究产出为系统架构描述，包含安全概念的架构实现、可测试性机制，验证全自动驾驶重型车辆的研发可行性，确保车辆在预设运行场景中具备足够的鲁棒性与运行可用性。该参考架构将优化现有各级自动驾驶原型系统，实现两大突破：①无需操作人员值守；②适用于商用车批量生产场景。
本文章作为ARCHER项目的组成部分，聚焦自动驾驶、功能安全与工业化（成本、传统系统复用） 场景下的架构设计方法。图1展示了研究范围的宏观框架。本文章的核心思路是：将自动驾驶视为现有组件平台的新增功能，识别自动驾驶功能安全集成的挑战，定义缓解这些挑战的方法、流程与工具。
因此，尽管文章中的研究工作常围绕自动驾驶展开，并深度应用自动驾驶核心原则与相关技术，但研究重心始终是架构设计方法。本文章提出的方法专为工业应用设计，依据ISO 42010标准定义功能安全架构视角，创建符合汽车功能安全主流标准ISO 26262的初步架构假设（PAA）视图。
1.1 假设与界定
由于研究涉及领域广泛，需对研究范围进行多项界定，明确研究假设与不涉及内容。
本研究仅针对道路车辆，不考虑工厂自动导引车、自动驾驶列车等受限场景的自动驾驶车辆；
本研究仅适用于研发概念阶段，从功能视角开展架构设计，不涉及研发后期的实现细节（如处理器架构选型）；
假设行业通用中间件（如AUTOSAR）可实现自动驾驶功能与硬件实现细节的解耦，不指定具体中间件类型；
研究核心非功能关注点为安全（尤其是功能安全），不重点研究自动驾驶系统的信息安全等其他属性；
不研究非概念阶段架构设计的功能安全问题（如工具认证），仅关注车辆运动相关危害事件（如碰撞）的故障与安全措施，不研究保险丝熔断引发火灾等非驾驶安全问题；
假设需求完整且正确，不评估需求的完整性与正确性；
假设可获取传统平台架构的功能视图（描述功能组件及交互关系），不研究传统组件的架构恢复等细节建模问题；
假设自动驾驶分阶段落地，逐步提升自动化等级与平台覆盖范围；
不研究自动驾驶的伦理、道德、法律与社会接受度等问题（如电车难题）；
案例研究主要以单车为系统边界，不包含智能交通系统、车队编队等车车通信相关的系统级问题。
本章阐述传统平台、ISO 26262标准、自动驾驶与驾驶员角色的研究背景，为全文研究奠定基础。
与车辆、环境因素相比，人为因素是交通事故的主要诱因（相关研究显示占比达93%）。自动化虽替代人类驾驶员、消除驾驶任务中的人为因素，但自动化系统并非绝对可靠，新增组件及其交互的复杂度会带来新的失效模式。
美国加利福尼亚州要求上报自动驾驶接管事件：
自动驾驶模式的解除场景，包括检测到自动驾驶技术故障、或安全行驶需测试驾驶员立即退出自动驾驶模式并接管车辆控制权的情况。
2017年加州自动驾驶路测数据显示，谷歌旗下Waymo公司表现最优，每1000英里仅发生0.178次接管。但结合美国2016年车辆总行驶里程3.2万亿英里的背景，这一数据的参考价值大幅降低。并非所有接管都会引发事故，但在无驾驶员即时响应的场景下，少量故障在原型车量产规模化应用后，可能产生灾难性影响。这是开展系统化功能安全研究的核心原因，下文将阐述工业界现行实践方案。
2.1 传统平台与重型商用车
汽车行业已从纯机械设计，逐步演进为复杂的软件密集型信息物理系统。现代汽车平台可搭载约100个物理分布式电控单元，实现约300项分布式功能；2006年数据显示，软件成本占整车生产成本的40%。这一演进让现代汽车搭载数千万行代码与大规模参数集，图2展示了2013款斯堪尼亚车辆的代码库规模：约1400个功能元素节点、15000条通信依赖连线，直观体现了软件的渗透程度。
上述数据均来自自动驾驶普及前的汽车平台，而自动驾驶将进一步提升汽车电气/电子系统的功能与复杂度。
现代汽车平台的另一特征是高可变性，为满足客户定制需求，每一次定制或新功能都会增加成本，这是汽车行业的核心关注点。因此，平台化研发通过产品线与产品系列系统化管理产品可变性，实现成本控制。单台车辆（如图2中的卡车）仅是单一产品线的一种变体，而产品线又隶属于更大的产品家族。
重型商用车作为为客户创造价值的工具，会根据客户业务需求进行深度定制（硬件、软件、机械部件）。车辆售后改装等特殊场景，也让客户可优化全生命周期成本。
汽车领域的机电一体化特性（机械部件与电气/电子控制系统的紧密耦合），以及可变性管理的共性功能隔离需求，使得电控单元通过总线互联、实现分布式功能的架构成为行业主流。特定分布式功能的变更，可能因硬件平台共享依赖影响其他功能。
平台化设计是汽车行业的核心原则，架构师需面向更大范围（而非单台车辆）优化架构。阿克塞尔松将架构设计分为革新式与演进式两类：演进式架构设计是架构师的日常工作，针对需求变更等小幅度刺激调整架构；革新式架构设计则针对重大刺激，整体规划平台并预留未来扩展能力。
本文章将自动驾驶引入视为车辆平台的革新式变革，这也是采用系统化方法的核心动机。
2.2 ISO 26262与安全生命周期
安全作为非功能属性，始终与汽车行业深度绑定。随着汽车电气/电子系统复杂度提升、软件依赖度增加，行业愈发重视功能安全（系统功能失效场景下的安全保障）。汽车领域功能安全的现行事实标准为ISO 26262，是安全标准IEC 61508在汽车领域的专项细化。
尽管ISO 26262存在应用争议（如现行版本不适用于重型商用车、标准对自动驾驶车辆的适用性存疑），但除了预期功能安全标准（SOTIF）外，它仍是功能安全分析的最优选择。
标准中对功能安全的定义为：消除电气/电子系统故障行为引发危害导致的不合理风险。ISO 26262提供了顶层参考生命周期与详细的技术研发流程，保障目标系统的功能安全。图3展示了标准的生命周期与流程概览。
安全论据是应用ISO 26262标准的最终目标，即证明安全需求完整且通过安全活动工作产物验证的论证文件。标准通过生成合规工作产物获取验证证据，需求设计用于识别并缓解概念、产品研发、生产与运营阶段的系统故障相关危险。
本文章仅聚焦概念阶段任务，下文总结标准中与本研究最相关的内容。
2.2.1 危害分析与风险评估
安全生命周期的起点是目标系统定义，即实现整车功能的单个/多个系统，也是ISO 26262标准的应用边界。完成标准5.4.1条款规定的需求定义后，启动危害分析与风险评估，系统化识别危险并分析风险。
风险评估采用ASIL分级，通过为危险分配严重度（S）、暴露率（E）、可控性（C），依据表1完成等级划分。未被划分为 QM 级的危害事件，需制定安全目标—— 安全目标是系统的顶层安全需求，生命周期内所有安全需求均由其推导而来。
2.2.2 功能安全概念与初步架构假设
功能安全概念（FSC）的目标是：从安全目标推导功能安全需求，将需求分配至初步架构（PA）组件或外部措施，确保安全目标达成。功能安全概念明确故障检测、缓解、仲裁逻辑与现有安全措施，论证设计方案的安全性。
该阶段的核心目标是定义与实现无关的安全行为，保障安全目标达成。标准假设初步架构具备与实现无关的行为，且初步架构与初步架构假设可互换使用；本文章则明确区分架构元素集合（初步架构） 与功能安全视角约束下的视图（初步架构假设）。
功能安全需求继承自对应安全目标的ASIL等级，需求分配的组件需按该等级的严苛要求研发。
2.2.3 需求分解与ASIL剪裁
高ASIL等级需求分配至组件，会因研发严苛度直接提升研发成本。ISO 26262标准9-5条款提供了ASIL分解工具，可将单一需求分解为两个冗余需求，单个需求的ASIL等级低于原需求，前提是架构组件具备足够独立性，可分别满足需求。
ASIL分解规则如下：
ASIL分解可应用于产品研发全阶段，是架构师应对复杂场景的核心工具：
- 复杂组件无法满足高ASIL等级的严苛要求；
- 高ASIL等级研发成本过高；
- 待集成组件未按ISO 26262标准研发。
正确使用ASIL分解可匹配目标系统组件能力与ASIL等级需求，实现成本节约。
2.3 驾驶自动化
大众认知中，自动驾驶将开启零事故、零拥堵的道路时代，优化城市土地利用、资源配置与全民生产效率。研究咨询机构高德纳2017年数据显示，自动驾驶正脱离技术成熟度曲线的峰值，标志着技术逐步走向成熟，投资者与社会的预期趋于理性。
但由于自动驾驶是近年热点话题，行业对其定义与特性存在分歧，需明确本研究的自动驾驶定义。
纯自动化功能已广泛应用于现代车辆，但多数自动化功能在责任、时长、运行设计域（ODD）上存在限制。例如，自适应巡航等高级驾驶辅助功能需用户激活后接管车辆；先进紧急制动等主动安全功能全程激活，但仅在特定场景短期替代驾驶员操作。部分整车制造商已推出有限“自动驾驶”功能，可在高速场景长时间接管驾驶任务。这些功能的共性是驾驶员始终承担责任，现行维也纳公约框架下的法律体系也基于这一前提。
此前德国联邦公路研究所（BASt）、美国国家公路交通安全管理局（NHTSA）的自动化分级已被弃用，行业统一采用SAE J3016标准的SAE自动化分级（表2）。
本研究聚焦SAE L3-L5级自动驾驶，自动驾驶系统激活时需同时承担以下责任：
- 依据交通规则完成车辆横向与纵向全控制；
- 监控道路环境中的其他车辆与危险；
- 确认运行环境仍在系统运行设计域内；
- 监控车辆性能；
- 执行应对操作避免危害事件；
- 无法处理场景时，切换（或尝试切换）至最小风险状态。
本研究聚焦 SAE L3-L5 级的另一核心原因：驾驶员不再参与自动驾驶系统的功能监控。因此，自动驾驶系统必须自主处理可能发生的故障，无法依赖驾驶员即时响应。这一选择的重要性将在下一节详细阐述。
本章阐述本文章的研究思路与背后逻辑：3.1节概述架构设计决策、安全与架构融合的问题阐述；3.2节明确具体研究问题。
3.1 问题阐述
架构设计的特性，限制了复杂平台设计的形式化程度。因此，安全关键系统与自动驾驶场景下的架构设计，需要适度的严谨性——既保障安全价值，又不阻碍研发进度。
研究人员将架构设计的多维特性描述为艺术与科学的结合。汽车平台架构设计需兼顾功能属性、成本、组织能力、目标市场、未来功能需求、传统系统限制等多重因素，最终方案往往是各类需求的折中。架构师需在信息不确定的情况下判断多重因素，做出影响平台多年的设计决策。
由于各类因素相互权衡、难以定义（如组织技术能力），架构设计流程的形式化难度极大，设计空间也过于庞大。架构探索策略及其局限性已有详细研究，学者试图总结工业界与学术界在自动化架构探索应用中的差距。
汽车行业因此普遍采用手动架构设计方法，架构决策多由利益相关方共识达成。尽管共识式设计在过往可行，但自动驾驶对功能安全的影响将彻底改变这一模式。意外故障场景下驾驶员兜底角色的消失，既提升了设计严谨性要求，又扩大了严谨性要求的覆盖范围。
设计决策分为两类：
- 核心决策：如特定场景的制动等级、传感器配置等；
- 辅助决策：如自动驾驶激活前轮胎花纹深度的检测逻辑、非自动驾驶电控单元功耗超标时的重启策略等。
两类决策均间接影响自动驾驶智能的功能（案例a通过动力学变化、案例b通过供电功率影响）。
自动驾驶平台复杂度提升、技术迭代加速，意味着设计决策需在平台生命周期内更频繁地重新评估，过往的假设与选择可能因新信息失效。例如，测试发现摄像头安装位置受水雾影响，40%的运行时间无法正常工作——这不仅降低自动驾驶智能功能，更会影响安全论据。
安全论据不仅包含合规验证的工作产物，还包括连接产物的论证逻辑，证明其完整性与正确性。假设安全论据要求侧摄像头与雷达冗余监控特定区域，摄像头40%不可用会导致冗余失效。解决方案可选择重新布置摄像头，但会影响目标识别算法、线缆长度引发的瞬态故障；也可选择为摄像头加装清洗系统，由另一电控单元控制，但会增加功耗、新增控制逻辑，同时提升电控单元的ASIL等级要求。
工业界在无实测数据时的设计决策，高度依赖架构师的假设。
驾驶员与其他道路用户行为的假设，也会影响安全论据。例如，自动驾驶系统开启危险报警灯后其他道路用户的反应、骑行者矛盾手势的解读，都会影响危害事件的可控性评估。核心组件的选型也依赖假设——假设应急车辆通过车车通信广播位置，可消除声学传感器的部署需求。
若不系统化追踪设计决策、假设与依据，并应用适配场景的方法，可能导致成本上升或安全水平下降。
安全是系统级属性，ISO 26262标准倡导的自上而下设计，需要基于底层组件行为的假设。
笔者认为，安全视角的形式化需求与架构设计流程的信息供给能力之间存在根本性矛盾。尽管架构设计全流程形式化无法实现，但可通过标准化、可复用的工作方法，将架构设计中的隐性假设显性化、可评审。因此，汽车平台系统化架构设计方法至关重要。
3.2 研究问题
为明确自动驾驶车辆在安全、商业、验证与确认视角的架构设计挑战，需确定自动驾驶智能与传统平台的耦合方式，挖掘各视角挑战并分析视角间的张力。文章的研究问题为：
自动驾驶智能与传统平台的耦合方式，会产生哪些影响？
ISO 26262是汽车领域功能安全的事实标准，提供识别与缓解车辆功能风险的参考生命周期。标准倡导的自上而下设计适用于全新系统研发，但与汽车行业传统组件复用降本的实践存在显著冲突。
初步架构假设是标准工作流程中的首个架构产物，是不确定性架构设计、传统平台复用探索研究的理想切入点。本文将初步架构假设定义为功能安全视角约束下的视图，并据此回答以下研究问题：
（1）如何从平台中提取传统子系统的领域详细信息，用于初步架构假设设计？
（2）如何管理信息不确定场景下架构师的决策行为，满足安全关键系统设计的可追溯性要求？
本章4.1节概述研究方法选择与选型动机，4.2、4.3节分别阐述有效性声明与有效性威胁。
4.1 研究方法
研究人员的研究框架，可直观呈现本文章的研究思路：任何研究都包含思想框架、具体方法、研究领域三大核心要素。图4基于该框架，结合本文章内容重绘。
研究是创造新知识的活动，将研究分为三大核心要素：哲学观（建构主义、后实证主义等）、研究设计（定性、定量、混合方法等）、具体方法。
如第3章所述，架构设计属于系统设计角色，架构师需综合功能与非功能需求，达成利益相关方满意的设计方案。多利益相关方、复杂诉求交织、需求平衡的特性，决定了架构设计方法论研究必须贴合复杂社会文化背景，才能具备实用价值。因此，本研究选择实用主义哲学观。
实用主义研究的数据采集，也与架构设计特性高度匹配——根据场景、系统抽象层级、工作产物阶段，灵活采用定量或定性数据。实用主义倡导的混合方法研究，不局限于单一哲学体系，可选择最优知识获取方法。本文章采用定性与定量结合的多源数据，表3概述输入、验证数据采集与验证策略。
系统工程领域的研究方法已有大量讨论，学者强调方法选型的重要性；研究人员总结了现有研究方法，分析了验证挑战，结论为：受限于场景唯一性，研究难以提出绝对结论。这一结论同样适用于架构设计领域，也让具体研究方法的选型成为挑战。
Ferris定义的工程设计方法，既贴合项目目标，又符合实用主义理念。本文章与Ferris的观点一致，将知识分为三类：陈述性知识、功能性知识、程序性知识。自然科学聚焦陈述性知识，而工程设计优先研究后两类 ——设计方案的功能实现方式、应用流程。
工程设计采用构建验证法评估设计有效性，即原型构建与分析，天然适配文章中的案例研究。
工程设计方法创造的知识具有确定性——在特定场景下解决问题，这也是其与行动研究的核心区别（行动研究将知识视为相对的）。工程设计的方案导向、满意而非最优原则，与信息系统领域广泛应用的设计科学研究思路一致。本文章采用其它研究人员的研究框架，图5重绘自相关文献：相关循环明确文章A的研究范围，设计循环通过文章B的传统系统信息提取、文章C的流程设计，构建所需组件与流程；严谨循环依托架构师经验、工业最佳实践（如 ISO 26262），输出子系统报告等设计产物，以及M1方法、ATRIUM流程等设计流程。
4.2 有效性声明
Robson将有效性分为结构有效性、信度、内部有效性、外部有效性四类，本节简要说明有效性声明，并阐述方法关联与有效性威胁。
4.2.1 结构有效性
结构有效性衡量观测变量对实际场景的反映程度。本研究通过两大方式保障结构有效性：
多样化研究方法：从受控示例到文章B、C的真实案例迭代，验证研究思路的稳定性；
学术与工业专家共同参与：文章B、C采用工业专家意见构建方法，学术专家负责评审；文章A的探索性研究吸纳学术与工业专家参与研讨会。
工业案例研究的优势是结构有效性缺陷可快速暴露。文章B采用易懂的启发式方法与详细应用示例，减少研究者与用户的理解偏差。
4.2.2 信度
信度指研究的可重复性与研究者偏见的降低程度，即其他研究者采用相同数据能否得出相同结论。定量研究的信度易验证，定性研究则较难。因此，文章A可通过量化数据提出弱信度声明，文章B、C因定性分析占比高，无法直接提出信度声明。
定性研究与案例研究的这一局限已被学界认可，戈拉沙尼主张重新定义定性研究的信度与效度；坎贝尔提出，定性研究的信度可通过流程审计、原始数据、数据简化产物、过程记录实现。本研究通过清晰阐述研究步骤、数据与流程，提出信度声明。
4.2.3 内部有效性
内部有效性衡量研究结论的质量，即结论能否准确解释观测结果。本研究将内部有效性视为严谨循环中专家评审的实用价值。文章B的子系统报告、文章C的输出产物与对照组结果对比，可验证内部有效性；文章A为后续研究界定范围，基于其结论的决策也验证了内部有效性。
4.2.4 外部有效性
外部有效性（普适性/可迁移性）衡量结论的推广范围。本研究的目标是推广至斯堪尼亚之外的汽车行业，因此研究设计中确保：文章A的关注点、文章B/C的角色与设计产物，均符合整车制造商通用实践或ISO 26262等相关标准。本研究可在汽车整车制造商领域推广，但不适用于其他行业。
4.3 局限性与有效性威胁
本节遵循鲁内松、费尔特的研究原则，评估有效性威胁并阐述缓解措施。
- 案例细节披露限制：研究需保密案例具体细节，仅阐述代表性案例与结论，可能遗漏方法细节，导致可重复性降低。缓解措施：通过出版评审、学术与工业研讨会、非项目相关工程师评审，优化研究内容；
- 定性研究的主观性偏差：研究有效性核心源于组织实用价值，本研究符合行业实践、被终端用户认可、集成至组织工具生态，但不声称是最优解，仅验证方案可行性；
- 专家多样性偏差：研究大量依赖斯堪尼亚专家意见，可能存在组织偏见。缓解措施：文章C采用姐妹组织对照组，文章A/B的研究思路比结果更重要，受组织目标影响较小；
- 研究者偏见：评审专家与文章作者分离，学术专家评审工业主导研究（文章C），工业专家评审学术主导研究（文章B）；
- 量化阶段未完成：研究尚未进入现场数据量化初步架构假设、ASIL需求分配与分解的阶段，存在未知因素可能导致文章B、C方法调整。
本章 5.1-5.3 节分别阐述收录文章的独立贡献，5.4节讨论贡献整合逻辑，形成初步架构假设架构设计方法论。
5.1 文章A：确定研究范围
研究目标与问题
文章A为立场性文章，通过多视角挖掘自动驾驶落地挑战，回答研究问题1：自动驾驶智能与传统平台的耦合方式，会产生哪些影响？
研究方法
文章A的研究分为两步：
（1）视角识别：ARCHER项目利益相关方（4名博士、4 名资深学者、3 名工业专家）召开研讨会，确定核心研究视角：
- 商业视角：成本、可变性、平台生命周期、上市时间等；
- 功能安全视角：ASIL需求平台扩散、安全关键功能交互等；
- 可靠性视角：元件数量增加导致可靠性降低、攻击面扩大、可用性保障等；
- 验证视角：自动驾驶智能可组合性、验证工作量等；
- 实现视角：自动驾驶智能与现有传统平台集成可行性等。
（2）案例设计与评估：设计5种自动驾驶智能与传统平台的集成案例，覆盖机电一体化全维度：
- 案例 1：机械方式集成；
- 案例 2、3：无修改集成传统系统，集成度逐步提升；
- 案例 4：修改传统系统适配自动驾驶智能需求；
- 案例 5：基于自动驾驶智能需求全新设计平台。
案例2-4的平台集成深度如图6所示。
研究通过案例聚焦多视角核心关注点，在具体场景中同步分析，而非孤立研究单一视角，凸显视角间的相互影响。研讨发现视角范围过宽，同一视角下不同案例的优先级存在差异，因此提取可量化评估的核心因素：
- 平台复用率高
- 复用偶然复杂度低
- 平台可变性低
- 前期研发成本低
- 全生命周期研发成本低
- 可靠性 / 可用性高
- 安全相关诊断依赖低
- 信息安全性高
- 平台验证便捷性
- 自动驾驶智能验证便捷性
- 信息流可控性低
第二步召开第二轮研讨会，由参与者按1-5分制为案例评分，收集量化数据开展分析。
研究结果与讨论
分析形成两类案例分组：
- 案例1-3：保留传统系统不修改，案例3为组内最优方案；
- 案例4-5：自动驾驶智能优先级高于传统平台，可按需修改平台，案例4为组内最优方案（支持渐进式修改，无需全新设计）。
图7为案例3、4的评分雷达图，原点距离代表因素优先级。研究结论为：案例3、4是自动驾驶智能集成的最可行方案。
文章A的核心贡献：
① 分类自动驾驶智能与平台的耦合方式；
② 从汽车行业核心多视角开展分析，填补传统平台自动驾驶集成研究的空白。
文章A为ARCHER项目与本文章界定研究范围，明确传统平台最大化复用的商业视角核心需求，为后续文章研究奠定基础。
5.2 文章B：提取传统系统信息
研究目标与问题
文章A证实传统组件复用是降本、约束新组件设计空间的核心需求。
传统系统信息需在研发与安全生命周期早期集成，初步架构假设是信息集成的最佳切入点。
文章B聚焦初步架构假设，回答研究问题2：
如何从平台中提取传统子系统的领域详细信息，用于初步架构假设设计？
研究方法
自动驾驶所需平台组件类型多样、数量庞大，对应信息也高度异构，因此设计M1方法实现可复用的信息提取。研究需完成以下子任务：
- 确定待提取的合适信息及其来源；
- 确定信息提取方式；
- 确定提取结果在安全生命周期中的应用位置与方式；
- 确定所需抽象层级与结果格式；
- 确定组织角色与方法内职责。
核心组织角色分为架构师、领域专家、安全工程师，领域专家是方法核心使用者，将专业知识提炼后交付架构师；架构师汇总各传统子系统信息，设计初步架构假设并交付安全工程师。基于复用动机，ISO 26262标准的概念阶段是传统信息早期集成的最佳节点。
研究评估已完成项目的工作产物，选定诊断规范作为信息来源——诊断规范直接关联子系统故障与失效模式，是功能安全的核心依据；其包含监控器触发条件、防抖时间、关联诊断故障码等信息，可直接对接现场故障数据，为组件选型提供量化指标。
M1方法适用于架构师认定的自动驾驶功能所需全部子系统，领域专家依据启发式问题完成子系统报告。问题设计围绕驾驶员移除对自动驾驶功能的影响，引导领域专家识别新场景下的子系统修改需求，每个问题均提供背景依据、案例与解决方案。启发式方法实现架构师与领域专家的关注点分离，让领域专家将专业知识抽象为架构师可用的信息。
案例研究选用斯堪尼亚的电子制动子系统（EBS），原因如下：
- 自动驾驶核心子系统，平台性能最优的制动系统；
- 自动驾驶功能首批必选复用系统，无需全新设计；
- 具备半冗余特性，平台存在其他制动方式（性能与鲁棒性低于 EBS）；
- 复杂安全关键系统，支撑防抱死制动等基础动力学功能，间接支撑先进紧急制动等法规强制安全功能。
研究结果与讨论
案例研究分析700余个诊断监控器，识别出平台固有冗余可处理的多项故障，同时筛选出40项子系统内部无法处理的EBS故障 —— 这些故障需自动驾驶智能或新增子系统处理。
研究采用定量档案数据（诊断规范） 与工业领域专家定性解读，领域专家与学术合著者评估M1方法的实用性，结论为：
系统化发现自动驾驶智能与传统平台需求，有效支撑初步架构假设设计；
可通过诊断故障码现场数据量化初步架构假设设计，确定组件失效率。
文章B的核心贡献：
① 创新提出诊断规范用于初步架构假设设计；
② 提出基于启发式的M1方法，聚焦自动驾驶功能的驾驶员移除场景。
案例研究证实，平台底层微小变更都会影响上层功能，安全作为系统级属性，受子系统细节影响极大。选用传统系统的自动驾驶功能，必须彻底分析新场景（无驾驶员兜底）的局限性：
新增子系统弥补传统系统缺陷；
避免新老设计功能重叠，控制成本。
资深架构师虽能通过经验完成上述工作，但失误难以避免；自动驾驶功能复杂度提升，会进一步提升架构设计失误风险。文章C提出的ATRIUM流程，将概念阶段架构设计流程形式化，缓解这一风险。
5.3 文章C：传统系统信息利用与不确定性管理
研究目标与问题
文章C部分解决研究问题2（应用文章B的传统信息），核心解决研究问题3：
如何管理信息不确定场景下架构师的决策行为，满足安全关键系统设计的可追溯性要求？
研究方法
文章C提出不确定性管理驱动的架构细化流程（ATRIUM），缓解设计决策的不确定性，追踪不确定性对设计决策的全生命周期影响。
下文总结ATRIUM流程细节，斜体为流程专属术语，区别于普通英文含义。ATRIUM 以 UML 活动图呈现流程，元模型明确数据元素关系，单次迭代为完整流程执行（图9）。流程核心是将信息分为感知确定域与不确定域：感知确定域的信息静态、可追溯、一致性可控；不确定域的信息可能发生变更。
假设是两大域的连接点，将不确定信息转化为感知确定信息。假设可对应功能目标、约束、运行条件或架构决策所需任意信息，为适配架构师多源输入需求，假设定义保持通用性。假设具备唯一有效性标识（有效/无效），可在流程任意节点添加。ATRIUM流程中，架构师主要在感知确定域工作，领域专家、安全工程师在不确定域工作，专家负责澄清与修正不确定域信息。
- 元素具备状态属性（传统/新增）：流程首次迭代前存在的元素为传统元素，流程执行中创建的元素为新增元素。平台由传统元素与ATRIUM流程新增元素组成。
- 组件失效方案（CFA）是失效模式与元素的唯一组合，具备状态属性（已处理 / 未处理）：已处理指基于当前流程迭代信息完成分析；未处理指未分析或新信息导致分析部分失效。
汇总输入包含前序迭代输出、组织技术路线图、元素信息；设计目标（DG）是失效发生时车辆的预期行为，每个组件失效方案对应唯一设计目标。设计目标由一个 / 多个子设计目标（SDG）组合实现（时序 / 状态表达），子设计目标可按需拆分，抽象层级由架构师确定。设计方案（DA）是实现设计目标的可行架构方案，每个组件失效方案独立分析：若现有元素无法实现设计目标，为其分配一个 / 多个设计方案；已处理组件失效方案仅在现有元素满足设计目标时，可关联零个设计方案。定义流程参数指确定元素、失效模式、设计目标，生成组件失效方案。
选型是所有设计方案中被纳入细化初步架构的子集，在迭代收尾阶段（生成修订架构）完成选型。
关联是信息实体间的连接，用于信息追溯。感知确定域的关联包括：假设-组件失效方案、组件失效方案-设计方案、设计方案 - 选型，确保选型可反向追溯至假设。
图10a展示了不确定域中的流程。关联同样存在于不确定域中，建立在澄清说明与假设之间，或任务与假设之间。澄清说明包含次级使用者（如领域专家）必须解答的详细问题。所有必要但不确定的信息会被转化为澄清说明并单独追踪。每个澄清说明都需要架构师基于现有信息与判断创建一个假设，以保证架构师能在感知确定域中推进工作。如果即便专家也无法立即获取该信息，该澄清说明就会转化为一项任务。“将澄清说明转化为任务”这一抽象步骤即指这一过程。任务会分配相应资源，并由专家负责在双方约定的日期前完成。任务的预计完成日期、负责架构师与专家姓名都会与任务一并记录。流程迭代结束时未完成的任务会转化为风险，并被收录到风险清单交付物中。这一过程由图9中的“生成风险清单”抽象步骤呈现。
澄清说明与假设永远不会被删除。已完成的澄清说明或任务（在与专家确认后）仅会被标记为已解决（即与该澄清说明关联的假设正确，或原有假设被标记为无效，并新增假设与相关组件失效方案、已解决澄清说明关联）。用于特定选型的信息关联永远不会丢失。ISO 26262标准的变更管理流程要求提交变更申请、开展分析、记录决策、依据与实施变更，这一要求在该抽象层级得到满足。
当满足以下条件时，流程迭代完成：(1) 无剩余澄清说明；(2) 无未处理的组件失效方案；(3) 已完成选型。选型仅在迭代结束时确定，原因是设计方案可能同时满足多个组件失效方案，从而减少系统所需的整体变更。ATRIUM流程不规定特定的选型方法，允许企业使用自有方案。
研究结果与讨论
文章C的核心贡献为ATRIUM流程—— 一种灵活创建与细化初步架构假设的方法，以及对问题的分析与案例研究结论。
ATRIUM中数据元素的关联关系如图11所示。ATRIUM的交付物包括：由细化后的初步架构（即选型结果）构成的初步架构假设、假设清单与风险清单。ATRIUM的结果解读方式为：细化后的初步架构在假设清单所列条件下有效，且受风险清单所列风险影响。此外，ATRIUM还会记录故障与假设之间的关联，便于获取前期迭代的设计依据。这为多方达成一致讨论提供了基础，相关决策可据此制定并保留书面依据。
ATRIUM的设计需求经多方利益相关者多次研讨会收集，并通过多个示例迭代优化。流程验证满意后，被应用于斯堪尼亚公司L3（3级自动驾驶功能）的设计中，以增强遗留系统抵抗单点故障的能力。
在领域专家的协助下，采用自适应方案对L3功能的已知需求进行扩展。案例研究中使用的设计目标，与实现特定组件失效方案对应的最小风险状态相关。研究确定了多种最小风险状态类型，例如基于故障检测时车辆运动的物理特征（如车速与道路相对位置）。同时，在选择合适的最小风险状态时，还考虑了环境特征、驾驶员接管能力、系统降级能力等其他因素。当不同设计目标所需行为存在共同特征时，会定义子设计目标封装这些共同行为，并将设计目标重新定义为子设计目标的序列。
该流程揭示了多项关于组件（包括遗留组件、新增组件与自动驾驶智能）的隐性假设，并有助于基于遗留组件的限制确定新增组件的需求基础。评审认为，该流程生成的交付物质量优于原有方法与同一功能的架构师对照组生成的结果。
5.4 结果讨论
本文章提供了一套相关的方法、流程与工具（文章B与文章C），即一套方法论，用于在文章A设定的背景下。
因此，本文章以自动驾驶为背景，实现了以下目标：
- 确定对汽车平台的影响：文章A；
- 论证复用遗留信息的必要性：文章A与文章B；
- 设计提取遗留信息的方法：文章B；
- 确定提取信息的使用位置（即初步架构假设）；
- 通过尽可能基于遗留信息设计新组件（约束可用设计选择）减少架构设计的不确定性：文章B与文章C；
- 通过追踪剩余不确定性对设计中所用组件的影响，减轻其带来的冲击：文章C；
- 设计复用遗留信息并系统化构建初步架构假设的流程：文章C。
基于遗留系统的设计是自上而下与自下而上架构设计方法之间的折中方案，它借助企业内部的现有知识与专业能力，约束平台新功能设计中需做出的选择，进一步减少纯自上而下架构设计方法所需的迭代次数。
文章A研究了多种自动驾驶智能集成入遗留平台的架构案例，探讨了行业内最重要的部分关注点之间的相互依赖关系。仅保留少量架构案例有助于明确论点范围，更清晰地讨论各视角面临的问题。文章A的研究结论（例如从安全角度看试图将自动驾驶智能与平台其余部分严格分离的效果有限、从验证角度看自动驾驶智能模块化的必要性、从商业角度看尽早交付与复用遗留系统的重要性等）有助于解答研究问题1，并对本文章其余部分的形成起到关键作用。
本文章的目标是协助架构师在概念阶段开发安全关键系统。为此，需要考虑主流功能安全标准 ISO 26262 的建议。在审查该标准及关于概念阶段主要架构输入（初步架构假设）的文献后，未找到令人满意的定义。
为明确架构师在初步架构设计中面临的问题，整个平台可划分为三个不同部分：(1) 待考虑的功能组件；(2) 平台中的其他组件；(3) 自动驾驶智能。使用该模型，研究问题2可分解为：
a) 选定特定功能组件（即部分1）后，对其他组件（即部分2）与自动驾驶智能的选择有何限制？
b) 在问题 a) 答案的基础上，需与自动驾驶智能一同设计哪些新组件？
该方法论提取遗留信息并将其作为初步架构假设设计基础的整体概念视图如图12所示。文章B利用这一任务分解，通过提供复用遗留信息的方法填充初步架构假设视图，从而解答研究问题2。文章 B 在子系统层面有效分析了自动化的功能级影响，明确了将特定子系统与自动驾驶智能一同使用的缺陷与风险。
M1方法利用诊断规范分析人员移除对整车的影响，使领域专家能够借助专业知识识别潜在问题与解决方案。通过使用诊断规范，该方法打通了设计与运维之间的闭环，借助规范与现场故障报告的内在关联，实现架构失效率的最终量化。基于启发式的方法与利用诊断规范闭合设计-运维环路的思路，均被视为本文章的贡献。
文章B的应用成果，被用于在文章C中强化架构设计流程本身，从而解答研究问题。该方法论虽无法消除设计决策中的不确定性，但能将不确定性显性化，并通过公开设计决策及相关假设，使架构设计流程可被评审。
文章C中展示的ATRIUM流程已在工业界多个案例研究中得到应用。
方法、流程、配套工具与视角的结合，形成了一套强大的方法论，用于应对自动驾驶架构设计面临的挑战，并为后续基于现场失效率量化初步架构假设提供支撑。相较于行业现有流程，该方法论在可追溯性、设计决策管理、假设与依据管理方面提供了更优的解决方案，其带来的额外开销被所产出的必要工作产物所印证。
本研究的总体目标是完成ARCHER项目的子目标，即创建方法、工具与流程，协助应对安全自动驾驶给车辆平台带来的重大变革。本文章所述的初步架构假设设计方法论的创建，意味着该子目标已达成。在审阅的学术成果与ISO 26262标准本身中，均缺少对初步架构假设的明确定义与创建方法。因此，本研究填补了安全关键系统设计领域的空白，旨在为希望改进流程以符合ISO 26262标准的整车厂商提供参考。
本文章所述研究成果已在斯堪尼亚公司内部多个渠道、出版物会场、学术与工业研讨会上进行分享，并根据反馈进行修改。所提出的方法论已在文章B与文章C发表前后，通过在斯堪尼亚公司的应用得到验证。
文章发表后，除进一步应用该方法论外，还新增了工具支持以协助数据管理，并减少使用该方法时的人工开销。该工具的原型已集成至斯堪尼亚的工具链中，该方法论现已被视为标准工作方式，因为它提供了必要的角色分离与平台内大型复杂功能设计所需的框架。
虽未纳入本文章，本研究的另一项贡献是推动ARCHER项目另一子目标的进展——即功能安全自动驾驶参考架构。在开展各类案例研究时，随着平台故障影响的分析，运行时风险评估假设的数量与重要性逐渐凸显。研究人员对该发现进行分析并制定解决方案，创建了受监督方法影响的、基于安全策略的架构。
这些解决方案包含设计时安全策略，用于在检测到或预测到故障时，限制自动驾驶功能的运行范围。这些策略使维持可预测运行范围的责任由监督组件承担，从而允许自动驾驶智能功能在该范围内自由运行。
免责声明：文中观点仅供分享交流，文章版权及解释权归原作者及发布单位所有，如涉及版权等问题，请您联系alpha.yuan@houwa-tech.com告知，我们会在第一时间做出处理。
10个月宝宝每天需要喝多少奶粉？
