青白江建设网站怎样做网络营销

青白江建设网站,怎样做网络营销,年报是否就是在工商网站做的,百度收录网站多久摘要未来#xff0c;车辆制造商希望在网络通信领域提供更高的灵活性#xff0c;例如在开发过程中以及生产后提供简化的更新和升级功能。为实现这一目标#xff0c;当前车辆内部架构领域正经历一场范式转变 —— 多年来#xff0c;车辆内部架构一直基于面向信号的通信设计。…摘要未来车辆制造商希望在网络通信领域提供更高的灵活性例如在开发过程中以及生产后提供简化的更新和升级功能。为实现这一目标当前车辆内部架构领域正经历一场范式转变 —— 多年来车辆内部架构一直基于面向信号的通信设计。面向服务通信的引入解除了集成电子控制单元ECU之间的静态分配关系。然而在这些面向服务网络的开发过程中新的挑战已然出现。本文提出了一种搭建此类网络仿真与测试平台的方法并阐述了相关挑战同时探讨了该平台可支持的潜在用例。其中信息安全是一个关键方面在开发这些架构之初就必须予以考虑。在未来的工作中我们计划通过集成新的安全措施等方式为网络增加更多服务以便在仿真环境中对其进行测试。一、引言受电气化、自动驾驶和车联网等趋势的影响汽车行业目前正经历一场变革。此外未来还应提升在用车的更新和升级能力并简化开发过程中的功能适配。在以往的车辆中仅采用面向信号的网络技术例如控制器局域网CAN协议。因此发送方和接收方之间的网络消息静态分配在开发阶段就已确定。待传输的信号信息如车速被静态分配到有效载荷内的消息中。例如若要在实际应用中添加一项需要或提供特定信号的新功能就必须对网络配置进行全面修改。为应对这些挑战面向服务架构SOA范式正被引入当前的车辆中。这使得基于动态通信模式的面向服务通信成为可能。因此服务提供者可以为消费者提供特定服务且服务在运行时可随时调用。SOA 范式应用于汽车以太网技术与 CAN 标准相比该技术除了支持高速传输速率外还能实现点对点连接。然而这种变革也对现有的开发流程及所使用的工具产生了影响。CANoe是汽车制造商和供应商广泛使用的一款成熟工具适用于仿真、测量和软件测试。基于 CAN 协议创建网络仿真时可构建一个包含所有消息、信号及相关属性如周期时间的整体数据库。但基于汽车以太网构建 SOA 仿真则需要新的流程。SOA 等新型通信范式要求在以太网网络的开发和测试中采用新方法。通过使用 CANoe 等仿真工具可在网络或服务部署到实际硬件之前对其进行开发和测试。本文提出了一种汽车 SOA 仿真方法并介绍了应用场景。二、背景一汽车以太网2015 年IEEE 802.3bw 标准对汽车以太网技术进行了规范。该标准也称为 100Base-T1基于 ISO/OSI 第一层通过非屏蔽双绞线电缆提供 100 兆比特 / 秒的数据传输速率。对于带宽需求较低且需低成本实现的应用10Base-T1 标准定义了 10 兆比特 / 秒的数据传输速率。在 OSI 较高层级2、3、4 层汽车以太网融合了传统信息技术IT中的多种不同协议。对于 SOA以太网与传输控制协议TCP/ 互联网协议IP或用户数据报协议UDP/IP 结合使用。与采用载波监听多路访问 / 冲突避免CSMA/CA访问方法的 CAN 协议不同汽车以太网无需此类方法因为其通信被指定为全双工传输。这使得两个网络节点能够同时发送和接收消息从而避免冲突。由于其物理结构为星形拓扑每条线路仅连接两个网络参与者因此不会发生冲突。二面向服务架构在车辆架构中集成 SOA 范式旨在为原始设备制造商OEM和第三方供应商提供更高的灵活性使其能够在开发过程中或实际运行时更便捷地进行更改。为此功能被划分为尽可能小的服务这些服务可通过编排来执行更复杂的任务。此外硬件和软件之间的解耦程度进一步提高使得功能设计与底层架构不存在静态依赖关系。例如功能开发人员无需知道某个传感器信号在哪个消息中传输或所需功能集成在哪个 ECU 上而只需了解车辆中可用的服务概况。在汽车领域目前用于车载 SOA 通信的协议包括基于 IP 的可扩展面向服务中间件SOME/IP和数据分发服务DDS。中间件充当服务提供者和消费者之间的协调者并基于 SOME/IP 支持以下功能· 序列化实现数据在 OSI 低层与高层之间的相互转换。· 远程过程调用RPC包括简单的 “即发即弃”FireForget模式客户端调用服务提供者提供的方法且无需返回值和 “请求 / 响应”Request/Response模式带有返回值的方法调用返回值通过额外消息传输。· 服务发现SD涵盖三个核心方面一是传输现有服务的状态信息是否可用二是支持消费者定位所需服务三是通过 SD 实现发布 / 订阅机制。· 发布 / 订阅服务提供者可提供事件通知Event Notification或字段通知Field Notification消费者可进行订阅。一旦事件或字段中的信号发生变化如座椅占用状态相关信息将通过事件帧发送给所有订阅者。这使得仅在发生变化时才传输帧从而最大限度地减少网络负载。与事件不同字段包含历史参考先前的值。· UDP 消息分段该功能允许通过 UDP 帧传输大型 SOME/IP 数据且无需分片。此外由于电气和电子架构E/E 架构中未采用信号到消息的静态映射该概念允许在开发完成后仍能添加新功能。新功能可作为升级项添加且所需服务可轻松订阅。三AUTOSAR汽车开放系统架构AUTOSAR标准的核心目标是将软件功能与所用硬件解耦以简化汽车软件的可复用性。这意味着 AUTOSAR 不仅包括操作系统本身还包含分层软件架构即基础软件层BSW、运行时环境层RTE和应用层。基础软件层也称为 AUTOSAR 协议栈包含多个模块和子模块负责处理通信、诊断或安全等特定任务。实际应用程序下方所需的模块如用于建立车辆通信的模块被称为 AUTOSAR 通信栈。目前AUTOSAR 有两种不同的平台变体经典 AUTOSAR 和自适应 AUTOSAR未来车辆将以混合方式集成这两种变体。经典变体主要针对传统 ECU 的面向信号通信概念。较新的自适应变体于 2017 年首次发布旨在支持基于可移植操作系统接口POSIX操作系统和面向对象编程的 SOA 范式。为确保两个平台的兼容性经典变体提供有限的面向服务通信能力。开发新车辆时OEM 将所有所需功能定义为软件组件SWC并以可扩展标记语言XML文件的形式提供相关接口描述。然后将软件组件分配给规划中的控制单元这些控制单元通过网络技术如 CAN 或以太网连接。相关信息以系统描述的形式存储在 AUTOSAR XMLARXML文件中。为便于交换这些描述会生成系统描述摘要供相关供应商在开发过程中导入使用。图1、SOA原则由服务代理、消费者和提供者组成四CANoeCANoe 软件在开发早期阶段及后续测试活动中就支持车辆网络及相关 ECU 的开发。除了对所有组件进行完整仿真外还可仅仿真网络的一部分并将实际 ECU 集成到仿真中。仿真 ECU 上的功能实现可通过 Vector 专用编程语言通信访问编程语言CAPL或微软.NET 框架完成。为仿真 SOA可导入不同的描述格式如.ARXML这些格式包含已定义的 ECU、服务和接口的相关信息。三、搭建原型网络本节的目标是搭建一个支持与实际节点通信的示例网络以阐释 SOA 原理并提供开发和测试平台。为此我们对不同的搭建方案进行了可行性评估见表 1具体如下所述。表 1、SOA 网络三种不同搭建方案的评估一原型实现方案1. 方案 1第一种方案是建模三个节点分别代表媒体播放器、导航系统和显示器。此外开发一个可连接到 CANoe 仿真并输出相应数据的实际节点通过以太网硬件接口实现与 CANoe 的连接。但该方案存在一些挑战首先新创建的 CANoe 示例尚未包含 SOME/IP 实现其次媒体文件采用 Windows 标准格式数据通过 Windows 标准工具显示此外实例化实际 SOME/IP 节点需要完整的自适应 AUTOSAR 协议栈实现。2. 方案 2Vector 已开发一款计算器示例该示例已应用于多个 CANoe 软件版本且包含 SOA 实现。服务提供者将各种基本算术运算作为服务提供消费者可通过 RPC 访问这些服务。该实现已提供 SOME/IP 描述支持将仿真服务提供者与实际网络节点消费者耦合。但挑战在于为使用 SOME/IP 功能需在实际节点上实现 AUTOSAR 协议栈这需要扎实的 AUTOSAR 知识和工具支持。相比之下可通过实际汽车以太网连接进行数据传输以便进一步分析。3. 方案 3另一种方案是使用另一台运行 CANoe 的电脑替代实际节点。这将简化实现过程因为无需进行 AUTOSAR 协议栈实现但需要额外支付 CANoe 许可费用。为确定最合适的方案我们进行了效用值分析见表 1。基于该分析方案 3 最为合适因为其已具备 SOME/IP 实现和数据序列化功能且可将配置数据存储在以太网硬件接口上从而简化了可重复性。尽管购买多个硬件接口及由此产生的成本带来了负面影响但方案 3 在时间投入方面具有优势其加权总评分为 83%。二实现过程该实现基于图 2 所示的结构包含两个 CANoe12 版本实例和两个 USB - 以太网硬件接口。CANoe 中已有的计算器功能用作 SOME/IP RPC同时实现了两个 SOME/IP 事件服务回声Echo、三角波Triangle。此外通过现有的 ARXML 文件将服务描述导入 CANoe。图2、原型汽车以太网的结构所实现服务的 SOME/IP SD 通信原理如图 3 所示。SOME/IP 节点 2 提供服务接口SIF为 11 的三角波Triangle服务该服务代表由该节点生成的三角波信号。节点 1 通过订阅事件组SIF 11消息订阅该服务服务提供者则通过确认消息响应。一旦信号值发生变化消费者节点 1将收到新的 SOME/IP 消息。此外节点 1 提供回声Echo服务该服务对所订阅的三角波服务进行反转处理。在这种情况下节点 2 作为消费者订阅服务接口SIF为 10 的回声服务。由于三角波服务的值定期变化回声服务也将以相同的周期时间发送。第二种服务类型为 RPC支持四种不同的方法加、减、乘、除。可通过图形界面在仿真中修改方法参数同时也可在图形面板中可视化服务提供者的返回值。这些服务通过 CAPL 实现并存储在仿真节点上。面板的图形元素允许与 CAPL 实现建立链接例如读取或修改变量。除 SOME/IP 配置外还需为每个节点分配相应的 IP 地址、媒体访问控制MAC地址以及交互层IL。交互层负责将仿真 SOME/IP 节点与实际网络硬件连接起来。图 3、两种不同服务类型RPC、事件的通信原理四、SOME/IP的安全性由于 SOA 服务分布在不同的实例上且需通过上述机制如发布 / 订阅进行请求因此 SOME/IP 协议的安全性问题应运而生。特别是通信参与者的真实性至关重要因为攻击者可能伪装成服务提供者提供被篡改或恶意的服务。此外近年来发生的车辆攻击事件往往导致车辆内部通信的真实性遭到破坏。近年来车辆安全受到了媒体、车辆制造商、供应商及研究界的广泛关注。因此相关标准如 ISO 21434标准和联合国欧洲经济委员会UNECEWP.29法规正在制定中这些标准和法规明确了车辆生命周期内安全保障所需满足的要求。对于面向服务架构而言这意味着所使用的协议必须具备抗攻击能力。为此本节将探讨 SOME/IP 协议的安全性相关方面。我们参考了文献该文献基于 “通过修复漏洞增强软件安全性和安全性HEAVENS”方法对 SOME/IP 协议进行了威胁和风险分析研究了服务发现、远程过程调用和发布 / 订阅等通信机制。威胁分析识别出了数据修改、读取、删除或服务操纵等威胁。在后续的风险评估中这些威胁被评为中高风险因为 SOME/IP 协议几乎未提供任何防范攻击的安全机制。因此应通过测试验证已发现威胁的实际可行性而安全机制的集成可作为进一步的研究方向。下一节将介绍本文提出的方法可支持的用例。五、用例所搭建的网络可用于多种用例。一方面它适用于实验室课程为学生提供面向应用的环境另一方面可用于研究并扩展以探索汽车功能的新方法。此外可通过网关与面向信号的网络技术如 CAN 总线耦合构建混合 E/E 架构进而用于研究传输延迟。特别是服务与面向信号消息之间的相互适配或反之带来了新的挑战。另一个新兴的研究领域是 SOA 网络的信息安全。基于威胁和风险分析可推导安全机制并将其集成到 SOA 仿真中。前文所述的研究已提出了部分可能的安全机制例如可在 CANoe 仿真中部分实现这些机制以测试其有效性。因此CANoe 可用于搭建测试平台支持基于上述 SOA 架构的安全测试。这使得验证已识别威胁的可行性成为可能此外还可通过在集成安全机制前后对架构进行攻击测试来验证安全机制的有效性。六、结论SOA 范式正被引入当前的车辆架构中。与传统的面向信号通信相比这种通信方式和网络开发发生了根本性变化为功能的更新和升级提供了更高的灵活性。然而搭建这些网络也面临新的挑战。本文阐述了如何实现基于 SOME/IP 的原型通信该通信包含仿真CANoe和用于传输汽车以太网数据包的实际硬件。但其中一个挑战是 SOA 通信的描述 —— 需通过网络描述文件定义这需要额外的工具支持和扎实的 AUTOSAR 知识。此外由于 SOME/IP 协议缺乏安全功能本文还强调了安全在 SOA 中的重要性未来应改进这一问题。可利用 CANoe 等工具搭建测试环境开展 SOA 安全措施研究以支持安全测试的执行。七、未来工作在未来的工作中我们将通过添加更多网络节点和服务来扩展 SOME/IP 结构但需要创建新的 AUTOSAR 网络描述文件并将其集成到仿真中。此外将开发和实现处理环境信息如摄像头和雷达数据的自动驾驶功能并测试模拟服务提供者故障的场景。受影响的客户端应能够在运行时订阅其他可用的服务提供者。此外可通过集成安全测试来扩展仿真构建测试框架。通过这种方式可通过模拟对系统的攻击来验证安全措施从而助力构建 SOA 中的安全通信场景。