当我们讨论软件，硬件，功能层面的分解与集成，从属及映射关系时，会牵扯出元件，构件，中间件，组件，模块，系统等很多概念，乱不乱？非常乱。但如果无法区别这些概念，在沟通的基础语言上就会出现大量问题，这是不利于产品全流程工作的。流程的第一步就是对各种概念必须有一个清晰的理解，才能在复杂问题的梳理过程中，找到脉络。

有几点需要提前注意

• 中文博大精深，一个词汇在不同维度是不同意思，很多词汇在不同维度是一个意思，要识别清楚。

• 看一个东西，它一定有多个角度，而之所以逻辑会混乱是因为没有先锁定一个角度，就去讨论一个问题。更重要的，往往还要会在多个角度切换着看一个东西，最后梳理清楚一个事情。

• 组件是一个最有用也最没有的概念，其往往是在一个视角下为了梳理内部逻辑而产生的概念，是递归的不考虑尺度的。固定视角切入下往往会明确一个最大的概念（比如总成），明确一个最小的概念（比如零件）来锁定了一个视角的思考范围，而中间的部分都可以被叫做组件，在大量视角中都出现，因此要重点识别，不能混淆。其在任何视角之下只有对内的含义，对外是没有意义的。

01硬件维度

首先从硬件视角出发梳理下，硬件简单说就是看得见摸得着的东西，这使其具有很多独有的视角（制造，装配，机械运动，电气连接）

零件是组成机器的基本单元，如螺母是一个零件。一般可以被独立制造（冲压，铸造等）出来的叫零件。合件的概念类似，由两个以上零件组成由不可拆卸的联接方法(如铆、焊等)联接在一起的叫合件，更高层面上看也可以作为一个基本单元使用。

从硬件机械运动的视角出发，往往有构件的概念

构件是指由各类零件装配而成的各个运动单元。机构中的构件可分为机架、原动件、从动件等，是独立的运动单元，可以认为是机械运动的基本单元

机构由各个构件组成的 。机构是机器的重要组成部分，机构的主要作用之一是传递和转换运动。

从硬件装配的视角出发，往往有组件、部件（总成）的概念

组件是一个介于零件和部件中间的概念，可以理解为一部分零件组合，满足了一个基本功能。

部件是为完成更高层面的装配要求，在结构上组合在一起协同工作的东西，由若干个组件、合件和零件组成。部件是流水线装配过程中的最小单元，车企往往也称其为总成。

然后我们如果从软件视角出发，软件是看不见摸不着的东西，虽然严格说代码也算东西，但是更重要的是在软件逻辑思路上会产生一些特定的视角。特别在设计，编程和建立在重用性的再设计上。软件的视角和硬件的视角有很大区别。

从软件代码文件（编程）的视角出发，有这么几个可见的组成部分

模块（编译单元）是能够单独命名并独立地完成一定功能的程序语句的集合（即程序代码和数据结构的集合体）。它具有两个基本的特征：外部特征和内部特征。外部特征是指模块跟外部环境联系的接口；内部特征是指模块的内部环境具有的特点，即该模块的局部数据和程序代码。可以简单理解为软件的最小单元。

组件的概念之前也解释了，是一个中间概念也开始说是大模块（组件），子模块（组件）其概念是递归的，其性质和模块一样。当不同的组件的组装形成更大的组件时候，实际就是软件集成。还有些特殊变体，比如插件，其也属于组件（模块）的一种，只是有很强的独立功能属性。

代码到真正交给人写的时候，往往都会从这个视角出发进行组织。

从软件重用性视角出发，有这么几个设计思想上的概念

组件在这里是一种对象（Object），C++叫组件，Delphi中叫部件，而在VB中叫控件。组件是对数据和方法的简单封装，可以通过生成实例（instance）进行逻辑组装。

构件（Component）是可复用的软件，可被用来构造其他软件。它可以是被封装的对象类、类树、一些功能模块软件等。构件分为构件类和构件实例，通过给出构件类的参数，生成实例，通过实例的组装和控制来构造相应的应用软件。和组件的逻辑类似，只是往往构件更复杂一些。

设计模式（Pattern）其实就是解决某一类问题的方法论。你把解决某类问题的方法总结归纳到理论高度，那就是模式。每个模式都描述了一个在我们的环境中不断出现的问题，然后描述了该问题的解决方案的核心。通过这种方式，你可以无数次地使用那些已有的解决方案，无需在重复相同的工作。模式是进行设计上的重用。

框架（Framework）是某种应用的半成品，供你选用完成自己的系统。框架一般是成熟的，不断升级的软件，更深层次其也代表了某种约束性，有特定的适用场景。

构件是代码重用，设计模式是设计重用，框架则介于两者之间，部分代码重用，部分设计重用。软件重用性硬要类比的话是一种思维上的“硬件装配”。

从软件设计视角出发，构架(Architecture)是最重要的概念，它是对软件系统的系统组织，是对构成系统的构件的接口，行为模式，协作关系等体系问题的决策总和。软件架构是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。如果你知道UML语言，其从软件系统不同视角出发，定义了用类图、对象图、包图、状态图、活动图、序列图、通信图、构件图、部署图等10种图。一个图就代表一种设计上更细的视角，每种视角下都有一些从属和组合上的定义。这里就不详细展开了。

在实现阶段，这些抽象概念被转化为代码的模块和组件，比如类图中某个类或者对象的设计，就会直接成为一个最小的软件模块。当然设计和开发大部分情况不一定在一个维度上一一映射。设计与开发的关系简单总结：

在软件和硬件之间，由于某些重用性的要求，产生了几个重要的“构件”，必须特别的说明，包括中间件、操作系统与数据库系统。其往往统一了底层的复杂性（包括硬件和操作系统本身）为纯软件逻辑的复用提供了支撑。

最后，从功能设计或其他脱离软硬件的抽象目的（安全，性能等）出发，存在诸如相关项，系统，子系统，元件等概念。这些往往都是从用户的不同诉求出发产生的视角。这种视角一般都会从两个互相匹配的视角切入。一个是单纯的系统视角，一个是和目的相适配的划分语言。这里我们从功能安全的视角出发，看下具体是什么样的逻辑，其实从产品视角出发的系统设计也是一个道理。

从一个单纯的系统视角出发

系统（子系统）的概念，举例来说，人体由运动系统、神经系统等八大系统构成，你可以理解为人体是一个系统，而运动系统、神经系统是它的子系统。系统往往都有明确的输入（感知器），处理（控制器），输出（执行器）组成，但必须注意的是并不是一个子系统就一定有配套独立的硬件和软件，其往往是一个复杂的映射关系。

硬件部件(hardware part)或是软件单元(software unit)是一个最小单元，但这里要注意的是在整个分析过程中，需要去理解的软件或是硬件的最小粒度。并不是一个物理上的概念。

组件（compone）同其他视角一样，是一个中间概念，非系统层、非基础性、具有逻辑性和技术性分离的东西。

从功能安全描述视角出发

相关项（Item）是一个安全问题的范围，可以是单个多个功能，或者单个多个系统，是功能安全危害分析与风险识别（HARA）的输入，并最终产生功能安全目标，以及往下的功能安全概念。

元件（Element）是功能安全概念阶段需要描述必要的功能安全需求，并分配这些安全需求到系统的功能要素。可以是事项(item)的任何子单元(sub-unit)。

04总结

做自动驾驶汽车研发的工程师，经常在沟通过程中在几个概念之间来回切换，除了扩大自己的知识面外，最重要的就是确认好一个概念所处的视角，并从这个视角出发展开思考，并习惯于针对一个东西，从一个视角转化到另一个视角。