Critical Windchill and FlexPLM Security Notice

Critical new security patches are now available. Customers are urged to apply the patches immediately.

Learn More
下载 PDF

在数字化产品交付中集成硬件和软件开发

早在 1969 年,阿波罗 11 号登月计划就需要大约 14.5 万行代码。现在,一架波音 777 飞机的代码行数已超过 260 万行。如今,可能需要多达 1 亿行代码才能将一辆现代汽车驶出车道。

软件在复杂产品中不断变化的作用

900X450

每一天,软件对我们世界的运作方式都变得越来越重要。产品包含的软件越多,开发起来就越复杂,出错的可能性就越大。与此同时,创新和将复杂的优质产品更快地推向市场的压力比以往任何时候都大。除此之外,还要高效管理硬件、软件和服务创新的并行开发流,确保透明度,并将所有这些功能集成到单个产品中。

制造商如果不想在优化复杂产品开发的竞赛中掉队,就需要大幅改进其流程、系统和团队思维,否则就会被从头开始就以复杂产品为开发目标的竞争对手所取代。

实现这一演变的关键:

  • 构建有条理的整体系统视图
  • 使用系统工程设计方法
  • 助力组织接受跨学科思维
  • 利用合适的 PLM/ALM 工具

软件复杂性带来的挑战

从商业角度来看,这些发展对制造商来说既是机遇也是挑战。这是一个机会,因为在竞争加剧和创新压力增大的情况下,软件驱动的产品可以加快开发速度,并为全新的商业模式铺平道路。

但挑战何在?

跨学科团队

从产品开发人员的角度来看,即使机械方面的差异有所减少,整个系统的复杂性也会因为所有这些软件以及这些组件之间的紧密相互关系而增加。此外,软件本身背后往往有不同的开发团队,他们都以自己的方式和速度管理创新周期。协调他们的工作并整合这些并行开发流是很困难的。

系统验证

制造商还必须考虑如何验证整个系统,尤其是在使用安全关键型产品的情况下。根据行业和产品的不同,标准要求每个开发步骤和变更都必须追溯到最初的要求。

脱节的工具链

用于软件开发的工具包已经发展成为我们今天所熟知的应用程序生命周期管理 (ALM),其流程模型已整合到现代系统工程中。然而,在许多公司中,过去和现在的重点都是管理许多单独的组件。确保从需求规范到成品的一致性,并不总是得到整个公司一致建立的产品生命周期管理 (PLM) 概念(方法和工具)的支持。

900X450

开发软件驱动型产品的两种常见方法

在主要专注于机械和机电产品的公司中集成越来越多的软件时,我们可以观察到以下趋势:

方法 A:将软件视为硬件附属物

采用这种方法时,软件被看作是硬件的延伸或补充(就好像“那一小部分软件只是另一个部件编号”)。软件组件等同于机电组件,并被分配一个部件编号。虽然您至少能够识别产品结构中的 ECU,但最终不可能识别单层 BOM 中的所有相互依赖关系。

方法 B:ALM 和 PLM 并存

在某些情况下,需要与 PLM 环境一起构建一个独立的并行 ALM 环境。这种情况用“我不知道他们在那边做什么,但我也不感兴趣”来形容再恰当不过了。

摆脱了机电开发的束缚,软件开发人员可以在 ALM 环境中充分发挥其动态能力。软件经过优化,可在短迭代中以非常敏捷的方式满足当前客户的需求。

然而,在完全分离的情况下,PLM 和 ALM 环境之间的相互同步通常会被忽视。不幸的是,这种不一致性会延续到生产和成品中

遗憾的是,上述两种情况都不适合实现机械工程、电子和复杂软件之间的功能共生。

请在本文的详细版本中了解这两种方法的优缺点。
单击页面右上角的“下载 PDF”按钮。

重新思考 PLM 和 ALM

优化软件驱动型产品开发的关键在于构建流程、方法和工具,以便为所有有关各方提供透明度、高效的协作中心以及他们蓬勃发展所需的全部工具。

话虽如此,仍然需要协调所有单独的领域,以确保最终产品满足所有要求,并作为一个整体发挥作用。然而,这不仅仅是一个工具和方法的问题。它还需要进行广泛而深刻的组织变革,而这种变革的意愿至关重要。建议指派专人在监督变革方面发挥积极作用,并为组织中的协调提供强有力的指导。

其次,需要在复杂的技术开发环境中主动控制协同开发过程。系统工程中使用的方法提供了合适的基础。其中包括非常有用的工具包,可用于根据共同需求调整产品或系统的所有组件。

至于是完全按照规定实施系统工程标准,还是仅仅将其作为指导原则,这只是一个偏好问题 – 当然,除非您必须向客户或其他有关各方提供符合特定标准的证明(如某些行业的要求),在这种情况下,它变得非常重要。

方法论基础

至关重要的是,您的公司需要选择适当的程序模型(例如 V 模型),并像使用指南针一样使用它。

这在软件驱动型产品的背景下意味着什么?至关重要的是,在一开始,您就要考虑产品应具备的功能以及它必须满足的其他要求(如标准)。这项工作应该尽可能公正地进行,并且不考虑具体的方法。

相关步骤包括:

  • 描述产品应具备的功能
  • 在架构阶段合理地划分系统
  • 提供相互依赖关系的初始抽象定义
  • 创建同步机制

阅读完整白皮书,了解这些基础步骤。
单击页面右上角的“下载 PDF”按钮。

正确使用基础组合

重要的是要记住,尽管我们尽力保持简单,但硬件和软件子系统之间的相互依赖关系可能很快就会变得非常多样化和复杂。因此,您的 IT 环境必须帮助您尽可能地跟踪所有这些相互依赖关系。

建立上面强调的方法模型类型可以奠定坚实的基础,使您能够应对挑战,在整个开发过程中可靠地开发软件驱动型产品。尤其是端到端系统工程,它提供了至关重要的支持。

如今,大多数公司已经以某种方式将这些概念付诸实践。通常只是缺乏优化和更有目标性的协调,只要转变观念,指定专人负责,并使用适当的工具来支持工作,问题就能迎刃而解。