MBSE实践之基于模型的软件开发


如今,我们已经有先进的驾驶辅助系统,无人驾驶,汽车电子电气和网络连接,所有这一切都已经被整合到汽车上,进而导致车载软件的份额实现了飞速增长。

现代汽车,特别是高端的豪华汽车,车内已经包含近2亿行代码,超过45个互联系统,这个软件规模已经超过了飞机和电脑的操作系统代码行数。随着创新策略的逐步实施,再加上车联网、人工智能、无人驾驶、新能源、混动车型等新兴技术的应用,整车中嵌入式软件比例越来越大。可以说软件已经在很多方面成为汽车行业决定性的差异化优势,但是也带来了一系列的挑战,例如如何处理软件的复杂性,如何保证软件的质量,如何对部署的软件进行维护,软件开发过程中的协调等。

MBSE实践之基于模型的软件开发的图1

图- 1汽车软件开发面临的一些挑战

  • 软件复杂性:过去十年内,汽车内嵌入式软件的产品数量呈指数级增长,并日益复杂化。例如,要为整车配置BCM应用,大约需要2500个软件参数。这一BCM应用可同时用于20个或以上不同型号车辆,而软件工程师则需要对这些车辆型号的2500个参数的独特和通用配置值集合进行管理……为支持车辆生产线,总共大约需要管理60,000至80,000个软件参数值。而这仅仅是软件应用的配置……更不用说为了支持车辆生产线的功能分解、控制、编码和测试方案所带来的复杂性了。

  • 软件质量:据估计,为了推动整车产品质量,在更依赖于软件交付的各项创新和新功能中,嵌入式系统占 90% 以上。为了向市场交付这些产品,必须采用更多跨领域工程方法,同时大量采用软件与产品的集成。就汽车行业而言,由于软件问题导致的车辆召回所产生的保修成本近年来大幅上涨,与软件相关的召回比率,已经从2011年的不到5%,增长到2015年的近15%。

  • 部署的软件维护:大多数软件工程工作都围绕着维护、升级已部署在市场中的软件展开,以此应对维修、更新和硬件兼容问题。随着软件复杂性日益增长,用于部署远程 (OTA,Over The Air) 更新等升级的机制也越发复杂。例如,需要针对特定产品版本追踪这些软件应用的二进制代码及其相应配置和校准值等。在全球范围内根据VIN来追踪车辆,以了解不同型号ECU拥有的应用版本内容和所需升级。或反其道而行之,变更软件给定的提议(可能是由于召回)。如此一来,可以想象一下全球有多少道路上的车辆会受到影响!

  • 软件工程协调:软件工程经历了漫长的发展过程,现已变得异常复杂,没有任何一款工具能够完全支持有效交付软件应用所必需的进程任务。因此,将所有必要的进程任务和相关扩展,融入到必要的工具集生态系统进行集中管理变得更加重要。

在软件驱动汽车的新世界中,最重要的挑战来自在产品开发不断加快的步伐下,汽车OEM和供应商能否快速转变以适应日益增长的复杂性和新兴趋势,确保新的市场机会,创新无疑成为推动汽车厂商在竞争激烈的行业保持领先地位的一种手段。

基于模型驱动的软件工程,是在汽车行业中大量使用的方法。Polarion基于项目模板,与Teamcenter平台、Mentor Capital平台、Simcenter平台以及模型工具,可以给客户带来科学的系统工程解决方法。它不仅支持软件全生命周期的过程管理,还可以和软件研发阶段的各种角色进行工作协同。在满足合规性的刚性需要下(比如:ASPICE,ISO26262,ASIL,能力成熟度模型集成CMMI等),实现软件在环、模型在环、硬件在环,提高软件复用颗粒度,保证产品质量并更快地进行交付,以满足汽车客户对汽车电子电气软件开发的需求,如下图所示。

MBSE实践之基于模型的软件开发的图2

图- 2 基于模型的软件开发过程

西门子的Polarion应用生命周期管理 (ALM,Application Lifecycle Management)平台,是解决汽车软件开发过程中各种问题的软件全生命周期管理解决方案。如图3所示,西门子Polarion ALM方案,是一套面向汽车软件研发的整个生命周期的系统,能实现从软件产品概念设计、软件需求分析、软件设计、软件构建和发布管理、软件测试管理、软件项目管理(包括敏捷和混合项目)、软件配置和变更管理、软件风险和问题管理、软件计划和资源管理、审计度量管理等,直至软件项目完成的全过程管理。

MBSE实践之基于模型的软件开发的图3

图- 3 Polarion平台的软件管理流程

Polarion作为软件生命周期管理的一体化工具,将软件开发团队和项目连接起来,使用单独的、统一的需求、编码、测试和发布解决方案,改进汽车软件开发过程。具体来说,Polarion具有以下特点:

  • 基于用户驱动的方式,让整个软件开发流程中的各个角色能基于同一个管理平台,进行工作协同和数据交付,实现软件研发模式的创新;

  • 可借助实时整合的管理信息提供报告和指标,让项目更透明,有助于开发团队加快协同速度,并以更高的质量来满足新的商机和客户需求;

  • 集成的需求变更功能,可以帮助研发人员在汽车软件的研发过程中保证软件质量,收集、管理和跟踪开发的变更请求,通过影响和跟踪分析能力确定哪些项目工件需要进行检查、修改或添加,同时更好的处理各专业部门科室的协作;

  • 不但可以帮助质量保证和测试人员轻松展开进行测试管理工作(软件缺陷检查、单元测试、集成测试、系统测试),还可以轻松创建跟踪,下至缺陷,上到需求;

  • 以数据为驱动,改变了传统的以文档为驱动的软件开发方法,产生了灵活的工作流程,通过结构化,工作内容细颗粒度化,让协同真正意义能落地,提高了敏捷性;

  • 通过对项目数据的监控,实现对开发过程的所有数据的质量把控,将质量保证部署在软件开发的各个环节,产生高质量的软件产品,以及高可控的管理流程。

MBSE实践之基于模型的软件开发的图4

图- 4 Capital Software Designer是E/E架构和软件详细设计之间的桥梁

西门子Capital Software Designer(CSD)能够承接来自于Capital System的架构数据信息,作为软件架构设计的输入,而Capital Software Designer的设计输出,也作为下游网络详细设计(Capital Networks)和进行满足AUTOSAR规范的ECU设计(Capital VSTAR)的输入。Capital Networks可以设计、分析和验证车载通信网络,然后再进入嵌入式软件实现阶段。在此阶段,嵌入式软件可以使用AUTOSAR工具Capital VSTAR为目标ECU进行设计和配置,并在Capital VSTAR Virtualizer中进行相关的虚拟验证。

在CSD中,软件架构设计可以以图形或文本两种方式体现。如下图所示:

MBSE实践之基于模型的软件开发的图5MBSE实践之基于模型的软件开发的图6

图- 5 CSD的图形化架构设计和文本化架构设计

CSD的图形化架构设计易于反映系统内部各模块间的信号交联关系以及各部分组成,对于从整体上把握系统架构原理有着得天独厚的优势;同时文本化架构设计可以直观反映架构设计中各模块端口信息以及端口约束条件。用户在系统设计阶段可以通过一键切换的方式,自由选择图形或文本方式进行架构设计。而CSD中架构设计中的每一个功能模块原则上都应有与之相对应的功能需求条目,系统工程师需要将功能需求中的所有条目都映射到对应的架构功能模块,关联关系一旦被创建,用户可以在设计、测试、验证的任何阶段,查看需求指标的满足情况。

另外,如下图所示, Capital Software Designer(CSD)能够与Polarion集成,进行基于模型的软件需求分析、软件架构设计、软件的单元测试和集成测试以及系统级别的验证等。

MBSE实践之基于模型的软件开发的图7

图- 6 基于Polarion和Capital Software的软件开发测试验证流程

国内外众多的主机厂的实践表明,基于模型的软件开发能够满足软件的一系列要求,包括实时响应、分布式功能开发、满足标准特性竞争需要、软件的确认和验证、软硬件的整合等,进而能够给主机厂带来极大的收益,包括缩短时间、减少成本、提高质量、增强协同、满足合规、大大提高软件生产力等。

MBSE实践之基于模型的软件开发的图8

图- 7 基于模型的软件开发满足不同的软件开发要求

文章来源Teamcenter黑带
默认 最新
当前暂无评论,小编等你评论哦!
点赞 评论 收藏
关注