要弄清楚ASPICE SYS.3的系统架构到底应该怎么去设计，还有SYS.3的架构接口又要怎么去验证，这里头的核心，并不是画一张系统的框图出来就算完事了，而是要把系统的需求，给分配到那些确实能做出来的系统元素上面去，把元素和元素之间，还有系统跟外部环境之间的那些接口，都给它定得明明白白的，然后再去证明，这个架构跟需求、跟设计上的那些约束，还有跟它相关的那些工程活动，是能够对得上的。Automotive SPICE 4.0这个版本，是进一步地强调了架构的一致性、设计的理由，还有SYS.3跟需求、硬件、软件，以及系统分析这些活动之间，要怎么去衔接好。

　　一、ASPICE SYS.3系统架构怎么设计

　　系统架构的设计，是应该从SYS.2输出的那些系统需求出发的，要把系统看成是好多个互相之间要打配合的元素凑在一块儿，而不是一下子就扎进了软件的模块，或者是硬件的电路这些很细的细节里面去。架构这个东西，既要能把它静态的组成给表达出来，也得要能说清楚，那些关键的功能，在元素之间到底是怎么流转的。

　　1、先把系统的边界和上下文给确定下来

　　在【系统上下文图】里面，去把系统它自己本身、外部的用户、车辆的网络、传感器、执行器、诊断的设备，还有其他那些跟它有关联的系统，都给它明明白白地标出来。

　　这个边界，是要去说明白，哪些功能是由当前这个系统自己来担着的，哪些能力又是靠外部的系统来提供的。要是系统的边界，老是变来变去的，那后头跟着的接口、需求的分配，还有验证的范围，全都会乱成一团，所以这一块，是应该先去完成跟相关方的确认的。

　　2、把系统的元素给分解开，并且把需求分配下去

　　在【系统架构设计说明】这个文件里面，去把主要的系统元素都给定义出来，然后再把系统的需求，一条一条地分配到跟它对应的那个元素头上去。

　　系统元素这个东西，它可以是软件的、硬件的、机械的单元，也可以是外头要依赖的那些对象，但是分解的粗细程度，是要能够撑得住下一层的开发的。在分配的时候，要去躲开那种，一条需求到头来谁也没有去管它的局面，也要躲开那种，好几个元素同时都在管，但是又没有讲清楚它们之间到底是怎么协作的局面。像性能、安全，还有网络的负载，这些横跨了好几个元素的需求，还得要给出一个整体上到底要怎么去实现它的法子来。

　　3、把行为和设计的理由给描述出来

　　架构这个东西，不能光是去把一个个元素的名字给它列出来就完了，还应该去说明白，在启动的时候、正常跑着的时候、往下降级的时候、出了故障在处理的时候，还有最后关机的时候，在这些个不同的场景下头，各个元素之间到底是怎么去交互的。对于那种很关键的分解、做冗余的方案、通信的方式，还有资源是怎么分的，都应该把选它的理由，还有那些被否掉了的方案，都给记录下来，要避免到了最后，架构就只剩下一个结果，却没有一个能拿来进行评审的判断依据。

　　二、ASPICE SYS.3架构接口怎么验证

　　在SYS.3这个阶段，接口的验证，它的重点是要去检查，接口的定义是不是完整的、是不是一致的、是不是能做得出来的，还有是不是能追溯得回去的。到了后面，真的把软件和硬件集成到一块儿以后，去做的那种动态的接口测试，一般是在后续的系统集成和集成测试这些活动里面才会去干的，可不能拿后期的测试，去把架构阶段的接口分析给替掉了。

　　1、检查接口的信息是不是完整的

　　在【接口定义表】里面，去把接口的双方、方向、数据的内容、单位、范围、更新的周期、时序、初始化的状态，还有异常的时候要怎么去处理，这些东西都给记下来。

　　对于那些总线的信号，还要去说明白消息的标识、在什么条件下发送、超时了怎么办，还有怎么去判断它是不是有效的；对于那种电气的接口呢，就要去记下来电压、电流、极性，还有连接的条件这些。光是在那里写一个接口的名字，是没有办法去证明，两边对接口的理解，是完全一样的。

　　2、检查接口跟需求是不是一致的

　　通过【需求追溯矩阵】这个东西，去检查一下系统的需求、系统的元素，还有接口之间的这种对应关系。

　　每一个很关键的接口，都应该是能找得到它是从哪一条需求那里来的，每一条涉及到了交互的需求呢，也应该是能落实到具体的架构元素和接口上面去的。要是接口找不到需求的依据，那就有可能是属于那种没有经过控制的设计扩展；要是需求找不到接口或者元素去承接它，那就说明了架构的分配，还是不够完整的。

　　3、通过评审和模型的分析去验证

　　是可以结合着架构的评审、序列图、状态图、数据流的分析，还有资源的预算检查这些东西，去对接口进行验证的。重点是要去确认，发送方和接收方，它们对于数据的定义是一样的，时序是能匹配得上的，错误的状态是能传递过去的，带宽、存储的空间，还有处理的时间，这些是能满足约束条件的。对于那种跟安全有关系的接口，还应该去检查一下失效了会怎么传播、监控的机制，还有降级跑的路径，是不是跟安全分析的结果能对得上。

　　三、ASPICE SYS.3架构设计怎么避免评审问题

　　SYS.3这个地方，经常碰到的问题，倒不是说没有架构的文档，而是文档里面，缺了那些能拿去执行的内容。系统的框图是画得很完整，可是需求没有分下去、接口的字段写得不具体、设计的理由也没有记下来，那这个样子，还是很难去形成有效的证据的。

　　1、不要把功能的列表当成是架构

　　架构是要去说明白，元素的责任、连接的关系，还有跑起来时候的行为的，光是把系统的功能拆成几个方框，那还是不够的。在评审的时候，是应该能回答得出来，每一项系统的需求，到底是由谁来给它实现的、需要用到哪些接口、出了故障以后，又是由谁来负责去处理的。

　　2、不要只去验证正常的接口

　　接口的分析，除了那种正常的数据传输以外，还要去覆盖到数据丢了、延迟了、超出了边界、是无效的、重复了，还有通信整个断掉了这些个情况。特别是那些诊断的、网络管理的，还有安全监控的接口，要是没有把异常行为给它定义出来，那到了后面做集成的时候，就很容易冒出来两边实现的东西，根本就不一样的情况。

　　3、把架构的基线和变更的记录保存好

　　把那些已经通过了评审的架构、接口的定义，还有追溯的关系，都给它纳入到【架构基线】里面去管理起来。

　　系统的需求、硬件的方案，或者是网络的设计，这些东西发生了变化以后，是要去做影响分析的，要把受了影响的那些元素、接口，还有验证的结论，都给更新一遍。不能只是去把架构图给改一下，却还接着去用老的接口表，和老的追溯结果。

　　总结

　　ASPICE SYS.3系统架构怎么设计，还有ASPICE SYS.3架构接口怎么验证，这里头的关键，是从系统的需求出发，去把元素的分解、需求的分配、接口的定义，还有行为的描述这几样事情，给它做完了。接口的验证，不能光是去看那根连接的线它到底在不在，还得去检查数据、时序、异常的行为、资源的约束，还有双向的追溯。然后再去通过架构的评审、模型的分析、基线和变更的管理，去形成一套证据，这样子，才能让SYS.3真真正正地变成后面硬件、软件和系统集成这些活动，一个共同的设计基础。