实现机电一体化:软件工程师是不同的

多年来，软件一直是控制系统的重要组成部分。控制系统软件的重要性持续增长。例如，在控制单元中使用更快的处理器可能会使产品性能更好，并通过使用更简单、成本更低的机械部件来降低成本，但前提是传感器和执行器控制软件足够好。软件密集、网络化的电子产品对于从工业到消费的各种产品的性能正变得越来越重要。越来越多的工程团队正面临这样的问题:如何将软件开发作为产品开发项目的关键部分来处理?[这包括基于机电一体化的设计，那些集成了机械和电子，包括嵌入式软件。]

软件开发工程师、方法和工具可以集成到产品开发团队中。例如，医疗设备、雷达子系统、运输设备、生产监控、航空航天和通信等行业和产品类型。其中一些公司使用的方法可以在新产品引入项目中帮助软件开发。

软件工程师是人

公司A的工程主管根据“良好工程”基准来判断所有正在使用的开发方法，包括软件和硬件，其中包括适当的需求框架，适当的信息和问题的调查，以及适当的签署和变更的沟通。开发团队规模适中(数十人，而不是数百人)。经过几年分布在多个站点之后，这个团队(对于硬件和软件)已经集中在一个站点。最重要的工程管理工具是周一上午的小组领导会议。

公司B的开发团队分布在世界各地。即便如此，在团队中每个人每天正常工作时间的一两个小时内，团队成员将进行45分钟的在线异常报告会议(耳机，IP语音，屏幕共享)。开发负责人证实，他曾想使用公司的问题跟踪系统来代替这次会议，但他很高兴能迫使相关小组领导直接接触。

在这两种情况下，人们之间的直接沟通被认为可以减少误解的机会，并使可能复杂的后续行动更好地表达和确定优先次序。然而，所涉及的产品和团队在许多方面都是异类。这两个团队主要处理软件;他们产品的电子和机械部分相对静止，并不是竞争优势的关键来源。工程设计与纯软件开发团队没有太大区别——硬件可以被视为特殊的外围设备。但是这些团队成功地将老式的、人与人之间的交流作为开发过程的核心部分是值得记住的。

软件是不同的

对于硬件在整个项目中所占比重较大的产品，有一系列的方法。

C公司强调了与项目管理相关的问题。软件作为一种产品开发技术的发展非常迅速，在采访时占了新产品开发成本的一半以上，并且“几乎是所有的问题”。然而，20年前，嵌入式软件一直局限于由专业分包商提供的少数高端产品。目前的项目经理主要是在公司工作多年的工程师。这些人的实际经验主要是电子硬件开发。开发组织使用产品团队结构。这造成了项目经理(主要是硬件开发背景)和5-20个主导产品开发团队中的2-10个软件工程师之间的不匹配。虽然没有危机，但当项目经理不能用他们自己的经验来指导和质疑决策、优先级，特别是软件人员提供的时间估计时，他们会感到不舒服。

D公司对这些问题有一个组织性的解决方案。它同样选择了产品团队作为开发项目的基本单位。和C公司一样，每个产品团队都有机械、电气、电子和软件方面的专家。近年来，D公司为电子和软件人员提供了一个额外的“家”，将他们分组到一个“控制系统”单元，然后将他们重新分配到产品团队，但作为一个略微自主的控制系统团队。从产品团队获得的目标、任务和优先级的全面管理。产品团队中的控制系统团队领导(对特定控制系统团队使用的实际工具和方法有很大的自主权)提供日常管理。

在研究访谈的时候，组织D的目标是更多地利用控制系统单元来开发更一致的工具、标准和库的使用，并找到方法来实现更好水平的重用(从专有技术到体系结构到平台电子设备和软件)。

中心，不标准

E、F和G公司用“软件能力中心”和“嵌入式软件”等名称描述了集中式软件组织，包含数十或数百名软件工程师。每个产品开发项目都涉及来自软件组织的高级人员，作为多学科项目设计团队的一部分。团队的产出包括架构大纲(在硬件和软件方面有广泛的共识)以及如何为项目提供资源的共识。通常这意味着一个规范被带回软件团队进行实现;有时，软件工程师与电子团队一起工作可能是一项临时任务。

这些公司软件组织内部的项目并不是孤立的;与非软件人员进行持续的交流。但团队中的嗡嗡声来自于对软件的纯粹关注。例如，团队可以自由地试验和开发敏捷方法。所涵盖的技能集和技术是多样化的，而不是标准的，主要是由产品的性质和最终将运行软件的底层电子设备驱动的。然而，软件开发和其他技术之间的同步是通过严格的阶段门或类似的过程来“保证”的。无论采用何种方法，软件团队都必须交付每个阶段门决策过程所需要的软件工件。

工具和技术

H公司对于软件开发所需的工具和程序，以及将这些工具和程序集成到其整体产品开发系统中的方式，有着非常清晰的观点。其思想的基础是应该有两个独立的流派。一个流程包含了所有的管理系统——产品生命周期管理(PLM)、应用生命周期管理(ALM)、工作流、问题跟踪、源代码管理、配置管理、变更控制和测试管理。第二部分涵盖了技术工具——需求管理、建模系统、软件集成开发环境、编译器、加载器、静态和动态分析工具、仿真系统以及测试开发。

H公司发现的一个关键问题(其他被研究的公司也发现了)是如何整合管理工具，尤其是PLM和ALM，以提供一致的图景。PLM技术通过管理机械和电子项目在工具箱中赢得了一席之地，并且经常与组织变革并行实施，以打破竖井并实现“产品生命周期”的思维方式。非常相似的评论适用于ALM技术，除了它起源于软件开发。PLM供应商的期望是，他们最终会调整他们的系统，以更流畅和灵活的方式处理软件。但工程经理们认识到，由于一系列原因，这不是一个简单的过程。一些原因涉及到潜在的方法和方法。

例如，软件人员习惯于以比硬件工程师快一到两个数量级的速度变化。这甚至被内置到开发方法中，在软件中看到的早期和许多原型的价值与硬件开发中的方法是不一致的(多年来旨在减少物理原型的数量)。有些原因是技术性的;例如，考虑PLM解决方案的核心材料清单结构。“完成”的软件文件(即，准备闪入内存芯片)可以像任何其他组件一样使用这些结构进行管理。然而，软件的源代码通常不太适合，当分布在多个文件中的源代码子树可能需要独立的修订历史，并且参数化的软件构建过程可能从相同的源代码或基于模型的软件定义创建不同的可交付成果时。

行动在哪里?

系统工程的v型模型仍然存在。许多受访者，不仅仅是那些来自汽车、航空航天和国防等系统工程领域的人，解释说他们使用它作为必须在项目中创建的工件的地图，并指出，“V不是一个工作流。”最常被引用的例子涉及测试。V模型作为一个有用的提醒，在V的左臂向下的需求级合过程中开发的每个需求都必须与V的右臂上的合适的测试/验证/验证过程相匹配。这导致了跟踪和可追溯性的活动，以精确跟踪上游需求与哪个测试规范相关。

许多行业都存在影响发展方法的条例;医疗器械的设计和制造就是一个很好的例子。在这里，降低获得和维护正确认证的成本是当务之急。软件方面e，这意味着ALM提供证据证明已批准的开发方法被遵循的能力与ALM可能提供的任何生产力改进一起被高度重视。

未来:模块化、接口

软件团队是那些需要用更少的资源实现更多配置、更快的产品变更和更少的软件工程师的团队之一。这意味着需要更多的重用，这意味着模块化、标准接口和“外部”软件组件的使用——例如，操作传感器的软件堆栈。公共平台等策略与组织这些工作的软件和硬件都相关。

产品线工程规程(本质上，在产品家族或整个产品组合的范围内减少标准部件和部件数量)解决了这个重用目标。受访者指出，对现有软件进行重用改造是非常困难的。一些人报告说，从源代码转移到模型作为软件的核心表示之后，软件重用得到了更好的改善(源代码或二进制文件或多或少是由模型自动生成的)。然而，尽管基于模型的软件开发已经在汽车行业建立起来，甚至在生产软件中已经成为常规，但其他行业将模型的使用限制在文档、早期设计和原型设计上。

从电子设计自动化(EDA)、机械、电气和软件学科中汇集技术工具，从而形成灵活的多学科模型，这一点不难达成一致。然而，这种融合的预期形式将有很大的不同，从使用复杂的工作流和数据接口技术的独立点工具的集成，到一个全新的技术工具集，其中需求只是技术配置模型的参数。

但至少这些模型改变软件开发的方式的愿景是一致的。软件开始时是作为整体模型的一部分的初始高级概要体系结构建议。这种架构将被无缝地开发成可以模拟的东西，然后进一步开发成可以执行的东西，最终成为最终的可交付产品。在一些片上系统开发工具中可以看到这是如何工作的，这些工具允许电子设计人员延迟选择硬件和软件之间的边界，直到项目的晚期，以及在模拟世界中，使用硬件在环和软件在环模拟。当这类工具的使用变得司空见惯时，软件工程师仍然会有所不同，但可能会有所不同。

- Peter Thorne是Cambashi的总经理。他负责新产品引进过程、电子商务和其他信息通信技术工业应用相关的咨询项目。他将信息技术应用于工程和制造企业超过20年，在用户和供应商组织中担任开发、营销和管理职位。在1996年加入Cambashi之前，他曾负责一家大型IT供应商的工程系统业务部门的英国分公司。由CFE Media内容经理马克·t·霍斯克编辑，控制工程，设备工程,Consulting-Specifying工程师,mhoske@cfemedia.com。

在线

研究方向:嵌入式软件开发工具

计划降低自动化项目风险

用S88设计做正确的柔性制造

www.cambashi.com

您是否具有本内容中提到的主题的经验和专业知识?你应该考虑为我们的CFE媒体编辑团队做出贡献，并获得你和你的公司应得的认可。点击在这里开始这个过程。