aspice中提到的系统架构设计，这个可能还要结合具体的产品来看，比如说有些可以用UML 工具来设计架构图， 也可以用Enterprise Archit等工具， 还可以用MATLAB。ASPICE是一套对项目质量要求很高的体系，其主干基本覆盖了汽车电子研发项目的所有主要过程。
一、aspice中的系统架构设计
aspice中提到的系统架构设计，这个可能还要结合具体的产品来看，比如说有些可以用UML 工具来设计架构图， 也可以用Enterprise Archit等工具， 还可以用MATLAB。ASPICE是一套对项目质量要求很高的体系，其主干基本覆盖了汽车电子研发项目的所有主要过程。
系统架构设计过程包括三个步骤：
1.建立一个系统架构设计(establish a system architectural design)
2.分配系统需求到系统架构设计的对应元素中(identify which system requirements are to be allocated to which elements of the system)
3.对系统架构进行评估(evaluate the system architectural design against defined criteria)
系统架构(system architectural)
可以理解为对一个描述了外特性的事物进行合理的拆分，拆分成多种元素。
对复杂的系统可以在多个层级上进行拆分。
如小区是城市的一个元素，楼房是小区的一个元素，住户是楼房的一个元素，卫生间是住户的一个元素…
我们往往不会在设计城市时就把卫生间设计出来，但是设计产品时却经常在大的架构还没有确定的情况下去纠结更低层级的元素。
体系认证：至少应进行一次分层设计，以体现该过程被执行。
系统需求是对外特性（功能和性能），系统架构是对系统需求的内在进行细节化。
简单的系统可能只有一个元素层级
复杂的系统需要基于某种标准进行多个层级的元素拆分
SYS.3.BP2: Allocate system requirements.
Allocate the system requirements to the elements of the system architectural design.
将系统需求分配到对应的系统元素中。
体系认证：要确保分配需求和元素有双向追溯关系。
项目实践：系统元素和系统需求绝对不是一一对应的关系，某个系统需求可能需要系统的多个元素，系统的某个元素可能会实现系统需求中的多个需求。
每个建筑师都希望自己能设计一座千年不倒的建筑，每个软件工程师也都希望自己的架构可以尽可能的延长寿命。
笔者曾就职于华为的网络部门从事C++后台开发，2009年转行做了嵌入式，于是把当时WEB架构的思路引入到嵌入式产品中，虽然10年来公司产品需求不断变化，硬件不断更新换代，但是这套架构的底层代码一直服役到现在。毕竟嵌入式产品系统再复杂，功能再繁多也多不过互联网。
就像虽然网络应用也都到手机APP上了，物联网也兴起了，5G转眼就普及了，但是TCP/IP还依然在用。
系统性的实体产品，大到飞机汽车，小到一片单片机，都逃不掉总线这种架构。
SYS.3.BP3: Define interfaces of system elements.
Identify, develop and document the interfaces of each system element.
给每个元素设计接口，就等同于把元素当成一个需要分析的系统（参照系统需求分析），描述元素外特性。
SYS.3.BP4: Describe dynamic behavior.
Evaluate and document the dynamic behavior of the interaction between system elements.
NOTE 2: Dynamic behavior is determined by operating modes (e.g. start-up, shutdown, normal mode, calibration, diagnosis, etc.).
为每个元素设计好自己的外特性后（可以称之为静态描述），要描述元素之间的“动态行为”，也可以说这些元素是如何相互配合完成功能的。
举个例子：
工人们要建立一条生产线，除了要规定每个工人要承担的工作之外，还要规定这些工人之间按照什么方式进行协作，比如生产线的工作顺序是什么样的，怎么开始，怎么结束，特殊情况如何处理，有问题如何上报等等。
题外话，很多管理者在工作中只设计员工的对外接口，不考虑员工之间的工作流程，就会导致员工之间合作障碍，从而让组织的效率低下。
体系认证：至少要把start-up, shutdown, normal mode, calibration, diagnosis,这些包含到动态行为中。
SYS.3.BP5: Evaluate alternative system architectures.
Define evaluation criteria for the architecture. Evaluate alternative system architectures according to the defined criteria. Record the rationale for the chosen system architecture.
NOTE 3: Evaluation criteria may include quality characteristics (modularity,maintainability, expandability, scalability, reliability, security realization and usability) and results of make-buy-reuse analysis.
体系认证：至少要制定和NOTE3一致的评估准则。
项目实践：在实践过程中，NOTE3的模块性、可维护性、可扩展性、可扩缩性、 可靠性、安全（security）可实现性、易用性这些方面都应该被考虑在内。
基于以上内容的评估模板也应该成为公司的技术评估模板之一。
SYS.3.BP6: Establish bidirectional traceability.
Establish bidirectional traceability between system requirements and elements of the system architectural design.
NOTE 4: Bidirectional traceability covers allocation of system requirements to the elements of the system architectural design.
NOTE 5: Bidirectional traceability supports coverage, consistency and impact analysis.
体系认证：
1.公司体系文件中要对系统需求的可追溯性过程进行指导。（已定义）
2.必须有一种能够可追溯的需求管理工具，如DOORS，否则几乎无法通过认证。（已执行）
3.覆盖率、 一致性和影响分析（coverage, consistency and impact analysis）需要有
项目实践：
以下各个环节都必须建立双向追溯，以确保产品的研发过程没有发生偏差。
用户需求–系统需求–系统架构–（硬件过程略）–软件需求–软件架构–软件单元–单元测试用例–软件集成测试用例–软件测试用例–系统集成用例–系统测试用例
双向追溯的工具可参考MATLAB。
SYS.3.BP7: Ensure consistency. Ensure consistency between system requirements and the system architectural design.
NOTE 6: Consistency is supported by bidirectional traceability and can be demonstrated by review records.
NOTE 7: System requirements typically include system architectural requirements. Refer to BP5.
体系认证：
1.公司体系文件中要对双向可追溯性的评审过程进行指导。（已定义）
2.必须有确认双向可追溯性的评审记录。（已执行）
项目实践：
每个需要确认的环节都必须进行评审，以保证结论的准确性。
通过评审来规避个人经验的不足。
通过评审来规避让个人承担重大责任的情况。
SYS.3.BP8: Communicate agreed system architectural design.
Communicate the agreed system architectural design and updates to system architectural design to all relevant parties.
体系认证：
1.公司体系文件中要对阶段性产物的沟通范围进行要求。（已定义）
2.必须有与相关部门沟通的记录。（已执行）
项目实践：
拿到各个相关部门对项目阶段性产物的认可，可以有效明确各方责任，避免日后产生扯皮的情况。
项目的变更，更是要得到相关方的认可。
As a result of successful implementation of this process:
1) a system architectural design is defined that identifies the elements of the system;
2) the system requirements are allocated to the elements of the system;
3) the interfaces of each system element are defined;
4) the dynamic behavior of the system elements is defined;
5) consistency and bidirectional traceability are established between system requirements and system architectural design; and
6) the system architectural design is agreed and communicated to all affected parties.
延伸阅读：
二、系统组件和接口控制评估的内容
在研究和理解系统需求后，进行系统架构设计时，即首先会进行模块划分，在整体架构层级，会有结构、硬件、软件的区分，而后进行系统需求的分配。不同的设计方案必然影响系统组件以及接口处理。在这里主要考虑两方面，一是系统组件数量，二是接口。“低耦合高内聚”不仅是软件架构设计中要坚持的设计思想，同样在系统架构设计中也要考虑，实现软件、硬件及结构的完全解耦，这对于系统和后续软件开发工作十分有利。
软件程序尽量与硬件驱动分离，同时针对软件模块，硬件模块也要根据功能场景，实现高度模块化。接口数量形式跟模块划分的数量及功能复杂度密切相关。务必追求模块数量分配合理、接口数量及形式分配合理、模块实现功能明确且高度集成的原则。
