远程和云诊断方法将在未来的车辆维修中发挥更大的作用。在落地相应概念时，安全性需要涵盖车辆电子设备，以及其与外部系统的交互和通信方面的所有领域。OB诊断既简单又困难
诊断的主要任务实际上非常简单：让一辆无法正常工作的车辆再次运行。通常情况下，首先要定位错误，然后进行修复，最后验证修复是否成功。错误基本上是以下两种类型之一：硬件错误，例如必须更换零件，或软件错误，其必须更新ECU软件。而当前，如果车辆出问题了，通常是将车辆开到或者拖到4S店进行问题分析和修复。对于卡车而言，情况有些许不同，其必须尽可能长时间地在路上行驶，按约定时间将货物运送到目的地，因此维修的时间取决于卡车的空闲时间，另外卡车的维修通常是预先判定大致问题方向，然后到特性领域的维修厂，例如齿轮维修车间。远程诊断和安全
随着整车E/E架构日趋复杂，软件复杂度越来越高，意味着问题出现的频率会增加，相关诊断以及修复过程变得越来越难以掌握。另外随着主机厂想尽量保证用户的粘性，以及提供良好的服务，这也就引出了一个解决方案是远程诊断：
1.通过远程OTA下载最新的ECU软件，在合适的时间重新烧录至ECU。2.定期检查车辆状态——通常使用基于云的诊断系统，通过对车辆数据对可能将出现的问题进行预判，并将建议或者维修车间预约推送至车辆中控或者驾驶员手机。
3.当车辆出现问题时，主机厂的诊断专家利用远程诊断，快速对问题进行定位，并将详细情况告以及维修建议告知驾驶员，减少车主的焦虑。由于诊断不仅可以读取车辆故障，还可以修改参数或更新软件、启动车辆功能、从ECU读取信息。这带来相当大的潜在危险，远程诊断的引入，风险就更大了。这就是为什么在安全性、完整性和真实性方面必须有足够的保护，例如确保第三方不能轻易从车辆读取车辆任何信息，以及不能篡改ECU存储和通信数据等。
在一般诊断系统中(如图1所示)，必须在多个点采取保护措施。首先保护应用程序(测试器和诊断系统)防止滥用，系统只有授权才能登入。然后所有本地和云数据都需加密，这样就不能再从外部读取数据了。最后所有的通信连接都必须加密，防止窃听。所有措施的目标必须是整体诊断功能的端到端保护，用户代表一端，车辆网关通常代表另一端。在车辆内部，其他保护机制是必要的。
加密中有两种基本的区分：对称加密和非对称加密，如图2所示。在对称加密中，涉及的双方都知道用于加密和解密的密钥，秘钥长度通常为256 位长的短密钥，该过程已经非常安全，并且还可以高效计算。但是加密密钥必须安全地保存，并且没有第三方能够破坏它，例如在个人接触中。
非对称加密在双方都使用一对密钥。公钥可供相关合作伙伴使用，该合作伙伴可以将其用于加密。私钥被安全保存，用于解密用公钥加密的消息。以这种方式，可以避免在对称过程中传输密钥的困难，尽管这里需要更长的密钥长度，这也会导致较长的计算时间。此外，公钥必须从可信赖的来源获得。合适的方法
为了实现安全的端到端保护，必须首先保护ECU中的应用程序， 不能通过更新整个应用程序或修改单个文件来破坏它，这通常通过许可程序和封装相关的应用程序部分来实现。 另外一个重点是用户还必须对自己进行身份验证，因为并不是每个碰巧拿到诊断仪的人都应该被允许访问车辆，也不是每个授权人员都应该能够对 ECU 进行编程。为此，角色模型可以存储在应用程序中，并在最简单的情况下通过注册过程（密码）进行保护。数据通常使用对称加密程序来保护，无论应用程序是独立的、本地的车辆还是在云中。相应的密钥必须安全地编译到程序中，并在运行时保存在内存中，以实现非常好的备份级别。这类加密程序的例子有Blowfish或AES，它们都代表分组密码，因此不会对数据大小产生负面影响。此外，它们都没有专利，可以在公共领域使用。通常使用对称和非对称混合加密的协议来保护通信连接。在初始化阶段使用非对称通信交换代码（或计算所需的组件）。然后，使用此信息和对称加密执行实际通信。密钥仅在一次通信会话期间对安全程序有效，然后被丢弃。这一个典型的例子是TLS(Transport Layer Security)，它通常用于互联网协议，例如https、VPN实现和MQTT协议中的物联网，如图3所示。TLS在初始化时实现握手，首先使用各种程序(RSA或Diffie - Hellman-Merkle密钥交换)生成密钥，通信伙伴的身份验证还使用带有受信任证书(X.509证书)的标准化过程进行。随后，使用初始化中协商的过程执行对称加密。与数据加密一样。
除了安全问题外，还有第二个需要克服的挑战：今天的诊断系统通常基于诊断服务，换句话说，它们必须为每个子任务触发诊断服务。然而，诊断任务通常需要几个子步骤，并且包含不同的ECU。通过远程连接，这会变得既慢又不稳定，这反过来又需要不同的系统体系结构。总结
随着当前通过人工使用诊断仪连接车辆诊断，到慢慢引入远程和云诊断进入维修领域。由于车辆内、车辆上和远距离的使用情况，需要对诊断系统的体系结构和安全要求进行重新思考。一些诊断功能必须移入车辆中，以独立于网络基础设施，并能够独立于测试仪在车辆中自主处理诊断。远程连接的安全性必须从用户身份验证到应用程序以及到车辆网关的连接路由进行整体规划。
关于 ASPICE 的理解
CAN FD网络设计提示和建议
详解汽车Bootloader设计
特斯拉Autopilot系统安全研究|附dbc下载
详解功能安全概念阶段
详细揭秘大众ID.4的高压系统
特斯拉Model 3的BMS系统
结合AUTOSAR和DDS实现灵活的车辆架构
