今天继续补课，之前个人的计划时间都被公司加班吃掉了，基本上没有自我提升的时间了。现在只能够是采取“报复性熬夜”的手段来补充一下相关的知识了，积少成多，总归会有云开雾散的一天。我觉得当今中国汽车电子行业能够把这部分文档看一遍的人应该是不多的，如果我能够浑沦吞枣看一遍应该也会有很大的收货。
今天看完运行时环境的简单的需求描述。
AUTOSAR应该应该提供变准化的基础软件。具体说来，不仅包括接口而且还有相关的行为描述。基础软件的实现对于用户不可见，可见的是一系列的服务。这样，在开发的时候基础软件只需要定义、实施、测试一次就可以在E/E架构的多个ECU中集成。一旦实现了这些，OEM的供应商以及OEM就有了一个不影响基础软件而开发自己应用软件的稳固基础。
尽量采用现在已经有的标准并且做一定的合并，这样可以保证之前的一些软件设计的复用。再过去的多年，大厂定制了自己的标准。为了能够实现一个通用的标准，如果有已经可用的标准，只要是能够满足要求AUTOSAR尽量采用已经有了的。例如，使用OSEK的操作系统、部分网络、网络管理等功能的使用，都是这方面考量的体现。
AUTOSAR需要支持常见的车规MCU，类似的MCU基本都是高度集成且过了认证的。对其支持的功能，包括数字I/O、ADC、PWM、各种通信、多核、存储保护、Flash等都要有一定的支持。这一条主要是针对MCAL的，为什么放在运行时中描述呢？可能这里的运行时不仅仅是RTE，而是整个的基础软件功能。对这个做了要求之后，各种需求就有了较多的覆盖，可以避免过多的功能放到复杂驱动。
需要提供非易失性存储服务，从介绍看，这个其实是类似于我现在接触的FEE的。
AUTOSAR需要提供对GPIO的标准化的访问。这里其实主要还是只服务，因为具体的设计对于用户来说是不可见的。而使用的场景则是对传感器以及执行器的一些应用软件层级的访问与处理。
AUTOSAR需要把SWC、ECU以及系统级别的管理进行标准化。这个主要是要处理各种不同模式下的行为一致性问题，保证SWC从一个控制器移植到另一个控制器上的时候还有一样的运行效果。
需要提供对于ECU的安全访问机制，从描述看有点像我现在熟悉的UDS以及XCP，这样，可以提供对于用户访问的一定的认证或者限制。
我最近工作中开始反复接触到这个概念，其实这个就是SecOC的功能。主要提供数据的校验、新鲜度的检查等等。在防止破解等方面，有一定的帮助。而这个功能这么看来并不是一个控制器内部的行为，更像是一个控制器之间的行为。当然，这个控制器的定义在这里可能又有说法，或许不同的控制器兴许只是一个MCU中的不同模块而已。
应该提供诊断手段，主要用于量产以及服务。至少应该要支持14229或者OBD这样的诊断标准。看起来，这个究竟支持什么也不是一个定死的行为。
为信息系统提供通信接口。
从上面的描述看，主要是用来做一个动态显示以及一些部件的配置操作。
提供功能安全的软件平台，支持系统安全相关的功能开发。这个其实是有些考虑ISO26262的设计的，可以实现软件应用软件以及基础软件之间的自由交互接口，同时保证ECU内部的通信安全。但是，这并无法保证系统的安全性，因为这个应该是在系统级别考虑的。
支持开发可靠的系统，主要从错误避免、错误检查、错误处理等各个方面来考量。可以减少汽车维修的时间。
这样，为这部分做一个大概的回顾小结。这个首先对于车规芯片的支持有了一定的要求，其次是划分了软件设计的可见范围，并且在服务层级标准化了存储以及GPIO等这样的应用。除此之外，要求有一个通用的通信协议规范，如果有现成的标准中会采用现成的，以保证以前软件的可用性。剩下的则是对SecOC的要求以及诊断的要求，而对于功能设计则要求了具备一定的自我诊断的设计。
