Unrestricted
妥善实施 ALM-PLM 集成的行动 计划
汽车行业的高级管理人员如何管理和控制他们的
软件资产
Unrestricted
掌握高科技，才能驾驭未来
汽车行业软件的演变
软件已经在许多方面成为汽车行业决定性的差异化优势。汽车工程师通常会选择利用机械、电子或软件 系统来满足功能需求。软件逐渐成为他们的首选，因为软件具有创建速度、灵活性和最低成本等优势。
信息娱乐、先进的驾驶辅助功能以及燃油经济性等相关差异化特性成为当今消费者制定购车决策的依据。
鉴于这些特性均会受到软件工件的影响，因此汽车公司在这些方面加大了投资，力争实现产品差异化。
汽车系统目前已然具有丰富的软件，而高端汽车包含的源代码更是多达上亿行。然而，有利必有弊，软 件可能包含未能检测到的缺陷，包括编码错误和设计瑕疵等。据估算，100 万行代码通常包含几十万个 测试前问题。更让人更惊讶的是，即便是已出厂的应用，有时也会包含几千个未经发现的缺陷。近年来，
这个问题表现得愈加突出，令人瞩目的汽车召回事件越来越多，其中很多都能追溯到软件问题。软件复 杂程度并非呈线性增长，而是呈指数增长。例如，开发 100 万行代码比开发 10 万行代码复杂 22 倍。
这种复杂程度方面的增长要求我们必须改进大规模软件开发的管理。
其中，最受软件影响的一个领域是传动系统的开发。过去三十年来，传动系统是汽车设计变革的中心环 节，而这一领域从未停止过演变的步伐。车辆数字化将继续发展，对机械和水力载荷的依赖也越来越减 少，这意味着将会产生越来越多的基于软件的系统，并将采用下一代多核电子控制单元 (ECU)。由此产 生的复杂性及其对安全性的影响催生了多项汽车标准，其中软件方面的关键标准是 ISO 26262（请参见 图 1，其中突出强调了软件开发生命周期各阶段必须满足的要求）。要符合这些新标准，汽车行业必须 在新流程和新工具方面做出投资，确保他们的系统满足监管要求。
图 1：ISO 26262 道路车辆功能安全标准第六部分
资料来源：Ovum
新闻媒体报道了一系列关于黑客入侵车辆软件的事件。例如，菲亚特克莱斯勒召回事件就是由于黑客通 过信息娱乐系统控制了吉普车。此外还有 Wi-Fi 攻击，即黑客通过拦截 RemoteLink 和类似的移动应 用，控制奔驰、宝马以及克莱斯勒等汽车。同样，丰田普锐斯不小心将收音机和蓝牙与转向、刹车和轮 胎压力监测置于同一个网络上，也发生了同样的问题。这些事例说明汽车行业急需提高车辆软件的可跟 踪性和安全性。
Unrestricted
应用生命周期管理 (ALM) 解决方案已发展成为软件开发生命周期 (SDLC) 复杂性和质量的一种管理方 式。随着工程产品内软件绝对数量的持续增加，许多大型公司开始采用 ALM 来应对软件开发的挑战。
通常情况下，汽车公司实施产品生命周期管理 (PLM) 解决方案来管理与产品创造过程相关的数据。然 而，这主要是机械设计数据。软件工程以往并不是 PLM 领域的必要组成部分，但这种状况正在改变。
随着软件在汽车行业中的不断普及，成为产品增值与差异化的重要因素，不可避免地需要将软件工程作 为涵盖所有不同领域的整体产品开发的一部分进行管理。只有改进 ALM-PLM 的集成才可能实现这一 点。
高科技公司开始挑战传统汽车制造商
无人驾驶汽车技术正在火热开发中，不仅奥迪、宝马、奔驰和日产等传统汽车制造商热衷于此，而且 Alphabet（谷歌）、苹果、特斯拉汽车和优步等高科技公司也纷纷投入研发。Ovum 预计无人驾驶汽车 在公共道路上行驶终将成为现实，目前，它们已经应用于采矿等私营领域。而且，Ovum 预计，到 2025 年底前，半自动驾驶汽车将驶上公路。据世界卫生组织统计，2014 年，全球因交通事故死亡人数 为 124 万人。政府将支持无人驾驶汽车技术，因为它在公共安全方面有着显著优势，能够减少交通事故 的发生。
当前汽车制造商将面临一个瞬息万变的形势，为了生存，他们必须控制使用软件的复杂性，不仅必须与 同行竞争，还需要与在高科技领域中具有专业经验的新市场挑战者竞争。因此，他们需要采用 ALM 的 成熟实践，利用 ALM-PLM 集成将这些实践发扬光大，这是应对竞争的不得已选择。
ALM 和 ALM-PLM 集成的行动计划
本报告提供有关汽车行业嵌入式软件开发管理解决方案的实用指导，包括内部开发的软件以及通过供应 链采购的软件。汽车制造商往往难以对所采购组件进行集成，工作项在整个供应链中的任何变更管理和 可跟踪性都是通过易于出错的手动步骤完成的。ALM 和 PLM 的集成采用连续工程交付通道，改进了车 辆内所有软件组件的管理，包括更好地利用自动化。
ALM 和 PLM 无缝合作，可以帮助汽车制造商更加大胆地进行设计与开发，充分利用软件为汽车带来的 优势。汽车行业高管与决策者可以方便地将他们的组织与本文所展示的 ALM-PLM 成熟度模型加以比 较，了解其成熟度情况，并遵循我们的建议和行动计划，这会令他们受益匪浅。
汽车产品软件管理的必要性
软件正在塑造新一代车辆
现在，几乎所有主要车辆系统内都包含软件内容：
信息娱乐：为所有乘客和驾驶员提供信息和娱乐的应用。
安全：从高级驾驶员辅助技术到自动安全操作和制动，再到无人驾驶。
传动系统：控制和动力机制目前也构建于电子和软件上。高科技混合燃料技术越来越能够 与火花点火引擎一争高下。
Unrestricted
基础设施：伴随着物联网 (IoT) 逐步对汽车行业产生的影响，汽车之间以及汽车和基础设施 之间的通信 (C2X) 也将随之发展。
为了规范汽车软件的质量、安全和安防，若干行业标准应运而生。其中，ISO 26262、ISO 15638 以及 来自例如英国汽车工业软件可靠性协会 (Misra) 等其他组织的类似准则尤为突出。ISO 26262 无疑是对 以往标准的改进，因为它要求进行基于需求的测试，以便创建需求并将需求与测试用例相关联。
尽管付出了上述所有努力，汽车行业在遵守合规性要求方面的成熟度还是滞后于某些行业，例如航空航 天业。因此，汽车企业必须快速推进，因为道路上的互联汽车越来越多，网络安全漏洞的风险将持续上 升。不可避免的是，监管规定只会越来越多。汽车制造商和供应商需要采取行动，提前布局，避免亡羊 补牢。汽车行业可以借鉴航空航天业的经验，在航空电子设备软件中应用控制与合规性机制，包括遵循 诸如 DO-178C（飞机系统和设备认证的软件注意事项）等标准。DO-178C 要求软件开发具有双向可跟 踪性，这意味着可在多个层面上跟踪系统需求，包括高层次需求和低层次的源代码规范。需求和源代码 可跟踪性是 ALM 工具的一个关键方面。
安全和安防将成为制造商难以承受之重
为了帮助制造商们管理电子设备和软件供应商的激增，汽车行业制定了一项开放型标准：AUTOSAR
（汽车开放系统架构）。AUTOSAR 要求定义软件应用与硬件之间的标准接口，以便能开发出基于组件 的模块化架构。该标准的优势在于促进重用以及管理供应商之间的互操作性。然而，所采购组件内的软 件内容对于汽车制造商而言就像是一个个黑盒子。例如，他们不知道组件里内置的是哪个操作系统。这 在过去无关紧要，因为所采购组件大多作为一个孤立的系统运行。然而现在，互联网连接的汽车出现了，
这种情况发生了颠覆性的转变，因为每个系统都是网络的一部分。如果所采购组件包含的计算机系统运 行的是过时的操作系统，由于它年限已久，必然有公开的已知缺陷，那么黑客就很容易通过组件接口对 其进行攻击。
今天高端汽车发生的网络安全问题的根源多数可以跟踪到不同车辆系统和组件之间的接口问题。安全关 键控制系统要与信息娱乐系统相分离，这是关键的安全要求，但违规情况时有发生，导致车辆关键系统 通过其信息娱乐软件而被控制。
汽车制造商和他们的供应商需要协调工作，来确保组件没有漏洞。汽车行业还需要采用应用安全思维，
思考安全对软件开发的意义。Ovum 建议使用软件安全开发生命周期 (SSDL)，它源于企业 IT，属于产 品设计和开发生命周期（见图 2）的一部分。在架构与设计阶段考虑安全性、威胁评估与建模以及连续 安全审查等概念都需要成为汽车行业的标准实践的一部分。这些做法将有助于提高汽车行业应用安全成 熟度的水平。
Unrestricted
图 2：软件安全开发生命周期 (SSDL)
资料来源：Ovum
评估 CISQ 软件质量标准
物理实体质量是可以直接评估的，然而软件质量只能间接衡量。因此对象管理团队创建了“IT 软件质量 联盟”(CISQ) 来帮助解决软件质量衡量的困难。CISQ 颁发了多项新标准（见图 2），开拓性地使用代 码相关规则与模式，根据四级标准（可靠性、性能效率、安全性和可维护性）对软件质量进行自动和客 观评价。CISQ 旨在补充 ISO/IEC 25023，在源代码级别实施这些可确保内部质量的措施。虽然 CISQ 主要针对于企业 IT，它的关键安全问题主要集中于软件丰富的工程产品，但 Ovum 建议所有行业都针对 这些质量标准的使用进行评估。
图 2：CISQ 标准 – 用于衡量四项质量特征和自动化功能点
资料来源：CISQ
Unrestricted
过渡到新的汽车产品开发方式
机械工程师曾经主宰汽车设计和开发
尽管原始的汽车产业是由机械工程师来打造的，但如今，这个产业却大不相同。自 70 年代末 80 年代 初开始，汽车企业开始采用 CAD/CAM 进行机械设计和开发。于是汽车设计和开发发生了转变，由粘土 模型和制图板转变为采用计算机数字方式完成。然而，现在，我们看到汽车设计又在发生模式转变，在 嵌入式电子产品时代，产品工程普遍采用 X-in-the-loop 技术和基于模型的设计，并在固件和应用中大 规模采用软件。
PLM 性质不断变化
传统方法依赖 PLM 解决方案设计、开发和构建机械产品，效果良好，行业内仍继续使用。然而今天，
软件在汽车中占领主导地位，PLM 解决方案必须随之发展。要达到所需的软件质量，同时又要加快从 产品全面启动到上市的速度，必须使用现代 ALM。这是汽车制造商和供应商在新的软件时代必须通过 ALM 功能来强化其 PLM 解决方案的一个关键原因。
Unrestricted
汽车工程师如何看待他们行业的变化
我们看到 ALM 工具行业正在发展以迎接在 PLM 环境下管理软件的挑战。PLM 技术提供商也开始认识 到，软件在工程产品中变得越来越重要，而且有不同的发展需求。与机械、电子和电气设计工作相比，
软件开发的节奏更快。软件变更更容易且执行更快，软件缺陷每年可发生 10 万次，远远超过其他工程 领域的一般缺陷数量。当今 PLM 系统的设计宗旨并不在于管理这些软件部分，而是要将专门的 ALM 解 决方案与 PLM 系统结合使用，这一观点已逐渐得到认可。ALM 和 PLM 流程之间的这种不匹配需要由 工具集成商妥善处理。
Ovum 与若干汽车行业软件开发人员和管理人员交谈，了解了他们在管理工程产品中的嵌入式软件和应 用的经验。ALM 供应商面临的其中一类挑战是：他们开始为企业 IT 提供工具，但工程中 ALM 的要求 却截然不同。ALM 工具必须支持：
交叉编译器开发环境，在开发机器上编译代码，而这些代码程序需要在不同的操作系统上 运行。
全球分布的组织协作 – 从小型开发团队到规模庞大的团队，成千上万的软件开发人员跨多 个站点协作。该工具应该能够运行各种不同的大量开发过程。
作为标准集成选件的建模与仿真工具 – 例如来自 MathWorks 的 MATLAB 和 SimuLink。
与 PLM 集成，这是唯一一个最重要的决策标准。工程师希望能够从 PLM 解决方案到 ALM 解决方案对软件部分进行跟踪，反之亦然。产品要求、变更请求以及软件缺陷跟踪是集成 PLM/ALM 生命周期的优先要务。软件测试可跟踪性也很重要，优先顺序次之。
从内部工具迁移到 ALM 解决方案
鉴于汽车行业产量极高，制造商具有强烈的动机来不惜代价解决自己的 ALM 需求。许多汽车公司使用 自有 IT 资源来构建自己的 ALM 工具。这显然是一个昂贵的解决方案，但到目前为止，汽车行业的选择 依然非常有限。在过去，过于依赖通过文档和电子表格来管理软件项目需求，时至今日仍不乏这种管理 方法。
虽然高级管理人员在董事会层面更关心需要交付什么，而不是如何交付，然而，在流程、安全和质量保 证工具上做出投资决策的却是各区域或各业务部门的高级管理人员。在来自下属工程师的压力或是自己 的方案所产生的压力之下，越来越多的部门领导都清楚了解 ALM 以及 ALM-PLM 集成的需求。这些挑 战在过去几年内并没有改变，然而应对这些挑战的需求却增长了。
只有将现场 ALM 工具与单一整体式 ALM 解决方案相整合，才能提供工作项的可跟踪性、
项目状态的可视性以及实时的分析和报告。
合作伙伴、供应商和汽车制造商之间工作项的无缝交换。
商业化的 ALM 和 PLM 集成。
市场上可选工具繁多，在解决上述挑战方面，某些工具可能优于其他工具，Ovum 建议决策者根据本报 告中列出的行动计划来评估这些工具。
Unrestricted
ALM 和 PLM 非常相似，但差异也很大
经过优化的 ALM 和 PLM 可管理其底层资产
如果您分析典型的车辆开发过程，会发现机械系统和软件系统的设计之间存在不少相似之处，特别是在 需求工程领域。然而，差异很重要。在 PLM 方面，高层次的工程需求进一步分解成各种变体、配置和 参数。汽车制造业的复杂性要求您更为精细地管理各项需求，相关配置与参数的变化成千上万。这些变 体、配置和参数使汽车制造商能够提供定制服务，满足客户的准确需求，还可以帮助管理现代汽车的复 杂性，加快产品上市的速度。这种需求精细化程度及其绝对数量是企业应用软件不可比拟的，所以 PLM 环境内使用的 ALM 解决方案必须有能够处理这种复杂性的需求管理功能。
在 ALM 方面，软件开发速度比机械和电子工程快，短时间内会发生数千个软件缺陷和变更请求。PLM 系统的构建尚不能应对这些快速变化的需求和变更请求，也不能满足管理与每个需求和变更请求相关的 多种测试类型的需求，其中包括开发人员、集成、系统、用户界面测试等等。目前，在 PLM 之外使用 专用的 ALM 解决方案是十分必要的。
PLM 和 ALM 可以提供明显优势，特别是当两者集成起来时，同时也才有可能对组件和软件加以重用，
通过例如产品线工程 (PLE) 等新技术提高效率。
PLM 和 ALM 集成的一个示例是 Siemens Teamcenter 和 Polarion ALM。图 3 显示了连接硬件和软件 的需求跨 PLM 和 ALM 解决方案关联起来 – 使用基于万维网联盟标准“资源描述框架”(RDF) 的双向引 用。
图 3：Siemens Teamcenter 和 Polarion ALM 集成
资料来源：Siemens
Unrestricted
ALM 系统在敏捷过程和方法以及最近的 DevOps 持续交付的影响下发生了颠覆性的改变。敏捷的工作 模式也影响着汽车的发展，主流制造商中通常都组建了 Scrum 团队。
Ovum ALM-PLM 成熟度模型
商业化 ALM 解决方案支持软件开发生命周期以及保障/安全、测试和监管等其他生命周期的每个阶 段。要了解 Ovum ALM-PLM 成熟度模型是如何应用的，我们需要考虑典型制造商使用软件的不同 方式。图 4 中纵轴显示工程软件的四种部署方式。在每一种情况下，软件都需要版本控制、变更管 理、测试和发布管理。
嵌入于产品中：出厂即部署于产品中的嵌入式软件和应用：传动系统、ECU、信息娱乐、
基础设施等。
数值分析与建模：工程师利用 CAD/CAM，开发基于软件的数值分析算法、模型和仿真，
这些都是宝贵的知识产权。
定制工具：在生产中使用的制造工具往往是企业专用工具，运行这些工具的内部开发软件 都具有宝贵的知识产权，例如机器人制造。
PLM：生产中的 PLM 实例及其所有定制与配置都需要一个管理解决方案。这些资产代表
着宝贵的知识产权。
针对工程功能中的这个软件开发活动，有不同级别的软件开发管理成熟度（见图 4）。
图 4：软件使用及其管理成熟度
资料来源：Ovum
Unrestricted
在图 4 中横轴成熟度级别适用如下：
临时工具：最坏情况是公司使用临时工具，例如办公工具（字处理程序和电子表格）以及 手动步骤。一位高级工程师因其所在公司使用电子表格来管理软件需求而感到沮丧，因为 任何工程师都可以访问电子表格并作出更改，而且不会留下任何审计线索。这种做法违反 法规遵从性。
现场 ALM：这是最常见的情况，企业有很多工具，不同团队、部门和外部合作伙伴以及供 应商都在使用各自青睐的工具。如果要集成这些工具，难度很大，而且集成并非始终可 用。如果正常工作活动中不提供这些功能，当审计人员来访时，工程公司会投入大量精力 确保工作跨各种工具的可跟踪性，一旦审计人员离开，工程师就又恢复原来的工作。
ALM 集成：当监管机构提高软件开发在工程中的覆盖率时，这个级别的成熟度将成为强制
要求。可跟踪测试用例生成、测试用例执行、测试评估、编码和发布到硬件等需求，以及 实时查看项目进度和跟踪工作项和团队性能，代表着成熟的软件处理能力。然而，此级别 上的集成只是在 SDLC 内。
ALM-PLM 集成：这是最高级阶段的成熟度。ALM 和 PLM 都完全集成在各自的软件和产
品生命周期内，但 ALM 和 PLM 之间的集成会提高成熟度。可以跨整个 ALM/PLM 边界无 缝跟踪工作项。在 ALM 或 PLM 方面工作的工程师可以跨所有生命周期管理工具获取信 息。
Siemens Teamcenter 和 Polarion ALM 之间的集成是 ALM 和 PLM 解决方案集成最高水平的最佳示例
（见图 5）。集成是 Siemens 搭建的 ALM 和 PLM 生态系统的一部分，还包括用于发布管理和加速软 件构建的电子云等其他工具。
Unrestricted
图 5：Siemens 和 Polarion 的集成设计与工程
资料来源：Siemens
Unrestricted
建议与行动计划
评估当前的 ALM 能力
Ovum 采访汽车工程师时了解到，许多汽车制造商已经开发并配备了内部 ALM 维护工具。这会给企业 带来负担，因为内部 ALM 应用所提供的功能不如商业工具那么丰富，从而产生额外成本。现在，先进 的 ALM 解决方案完全集成在整个生命周期内。这些解决方案为工作流程提供了瀑布式（门径式）敏捷 和混合或自定义管理方法。我们的建议是：
评估当前的 ALM 工具
如何捕捉需求？如果您使用文档进行需求收集，您必须确保您有一个 ALM 解决方案，可以将 这些文档转换为可审计需求管理的结构化需求。如果您只是使用电子表格来管理需求和规格，
那么您就迫切需要重新评估 ALM 解决方案策略。
您是否在全公司内建立并积极使用标准化流程，以便工作资产在全球各分司、供应商和合作伙 伴之间进行无缝转移？使用单一的 ALM 解决方案，您可以加快软件开发的速度，减少团队和 供应商之间的摩擦。
您是否使用开源工具进行核心开发、源代码和版本控制、集成开发环境、测试工具等等？开源 工具的优势在于可以使用当前流行（往往是最优质的）解决方案进行代码开发。但是，您必须 寻找相应的 ALM 工具，以便能够集成您的开源工具以帮助管理项目数据，同时提供管理工 具。
评估您的 ALM-PLM 集成能力
要受益于软件工程支持的最新技术进步，请查看您的 PLM 解决方案版本，并考虑升级至具有 ALM-PLM 集成优势的版本。
ALM-PLM 集成需要保持顺畅无阻，以便工程师可以实时无缝使用工具。集成将允许工程师跨 产品各个阶段和软件生命周期来跟踪工作项，从而提高协作和知识共享。
评估软件安全开发生命周期
通过软件安全漏洞入侵高端汽车仍然是汽车行业的一个关键弱点。有些用于保证软件安全的操 作实践是比较可靠的，例如威胁建模、“结构安全”架构、输入验证、攻击面分析、静态分析、
动态分析、渗透测试、持续安全审查。这些实践需要构建于嵌入式软件开发生命周期中。
本报告显示软件具有双重性。一方面，软件给当今的汽车带来了难以置信的价值，它正在转变汽车行业。
另一方面，软件难以管理，尤其是大规模创建软件时，容易带来质量、安全和保障挑战。行业标准机构 正在开始采取行动，应对提高软件开发管理的需求，但汽车公司也可以比监管者和竞争对手先行一步，
既利用软件力量，同时管理好其难以驾驭的本性。
Unrestricted
附录
作者：
Michael Azoff，首席分析师，软件解决方案 [email protected]
Tony Baer，首席分析师，软件解决方案 [email protected]
方法
Ovum 在 ALM 领域及其在 PLM 领域的应用进行了广泛研究和体验，以此为基础完成本分析报告。另 外，还采访了全球各地负责 ALM 的汽车工程师，包括法国、印度、德国、英国和美国等国家。
Ovum 咨询公司
我们希望本分析能帮助您做出明智的独创性商业决策。如果您有进一步要求，Ovum 咨询团队将随时为 您提供帮助。有关 Ovum 咨询服务的详细信息，请直接联系 [email protected]。
版权声明和免责声明
本产品的内容受国际版权法、数据库权利和其他知识产权保护。这些权利的所有者是：Informa Telecoms、Media Limited、我们的附属公司或其他第三方认可证颁发者。本产品内包含或显示的所有 产品和公司名称及徽标均为其各自所有者（包括 Informa Telecoms 和 Media Limited）的商标、服务标 志或贸易名称。未经 Informa Telecoms 和 Media Limited 的事先许可，不得以任何形式或任何方法复 制、再版、分发或传播本产品。
尽管我们已努力确保本产品信息和内容自首次出版之日起准确无误，但对于其中可能出现的任何错误、
遗漏或其他不准确信息，Informa Telecoms 和 Media Limited 以及受雇于或工作于 Informa Telecoms 和 Media Limited 的任何人员均不承担任何责任。读者应独立验证任何事实和数字，我们不接受与此相 关的任何责任和风险 – 读者使用此类信息和内容时，应相应承担全部责任与风险。
各位作者或供稿人通过本产品中表达的任何观点和/或意见均为其个人观点和/或意见，并不必然代表 Informa Telecoms 和 Media Limited 的观点和/或意见。
Unrestricted 联系我们
www.ovum.com
全球分公司
北京 迪拜
中国香港特别行政区 海得拉巴
约翰内斯堡 伦敦 墨尔本 纽约 旧金山 圣保罗 东京
