汽车网络安全管理系统初探

原创 智能汽车开发者平台 2022-09-23 08:30
摘要


网络安全越来越被认为是汽车系统的一个重要话题,特别是在联网和自动驾驶领域。即将出台的法规对汽车领域的网络安全提出了多层次的要求,以获得型号批准。在组织层面,需要一个涵盖整个车辆生命周期和生态系统的网络安全管理系统(CSMS)。此外,必须对申请型号批准的每一种车辆类型的网络安全进行论证。由于这些要求与现有的型号批准要求相比具有新颖性,因此正在进行测试阶段。CSMS的组成部分和范围是一个开放的问题。本文概述了CSMS的要求,确定了方法和差距,并对能够满足这些要求的潜在框架进行了展望。


I.简介
汽车正在从孤立的、主要是电子机械系统向带轮子的连接计算机发展。目前,这是由监管和汽车工业提供额外服务的愿望所驱动的。进一步迈向部分和全自动化的车辆只会加速这一趋势。像进一步减少交通事故或减少交通能源这样的目标,只有通过合作和自动驾驶车辆才能实现。为了实现安全、自动化和交互的车辆,网络安全需要提高。最近的评估和披露显示,目前车辆的几乎所有连接元件都存在多个漏洞。
图1. 参加车辆法规协调世界论坛的国家
为了确保越来越高的安全水平,联合国欧洲经济委员会(UNECE)WP29自动驾驶/自主驾驶和联网汽车工作组(GRVA)启动了一个网络安全和软件更新(CS/OTA)的特别小组。图1给出了作为UNECE WP29的缔约国的62个国家的概况(状态2016)。签约国意味着在这些国家销售车辆所需的车辆型号认证是基于ECE的法规。在此,我们将重点讨论整车型式认证(WVTA)。图2给出了关于车辆类型批准过程的概述。
图2. 整车型式认证(WVTA)过程
该工作组制定并提交了一份关于整合网络安全和软件更新的法规以进行车辆类型审批的建议。关于网络安全的建议包含以下几章:
(1)简介
(2)定义(和缩略语)
(3)网络安全原则
(4)对车辆系统和生态系统的威胁
(5)缓解措施
(6)网络安全程序的要求和如何证明其应用
(7)结论和对进一步程序的建议
(8)附件A 关于引入网络安全条例的建议草案
(9)附件B 威胁和相应的清单
(10)附件C 与缓解措施有关的安全控制措施清单,包括例子。
(11)附件D 参考文件清单
根据已交付的建议,目前有一个测试阶段正在进行。在这个测试阶段,对需求进行评估,必要时进行完善。同时,指导文件也被制定。
在第二节中重点讨论了网络安全流程的要求和如何证明其应用,以及附件A关于引入网络安全条例的建议草案,以确定和分析汽车领域的网络安全流程要求。

之后,在第三节中概述了汽车网络安全的现有构建模块和开放点。在第四节中,提出了一个起点来定义一个符合CSMS的流程,涵盖整个生命周期。


II.对网络安全流程的要求和拟议的法规
建议的要求分为三个部分。第一部分描述了汽车行业中网络安全管理系统(CSMS)的要求。下一节描述了后期生产阶段的要求,最后一节涉及到车型的批准。对于拟议的法规,有一个章节描述了cms合规证书,一个章节描述了网络安全管理系统的要求,然后是车辆类型的要求。在下面几节中总结了这些需求。
A.网络安全管理系统
网络安全管理系统是一个总的结构,它收集了所有与网络安全有关的过程。汽车制造商必须确保供应商和服务提供商实施CSMS。  制造商及其供应商和服务提供商的CSMS由审批机构或技术服务部门评估。虽然审批机构或技术服务部门可以在任何时候要求重新评估,但基本有效期为三年。如果有可能影响评估的变化,车辆制造商必须通知审批机构或技术服务部门。CSMS中定义的流程必须包括开发、生产和后期生产,并考虑对车辆的风险和威胁的监测以及事故响应流程。
对于流程的定义需要在汽车领域的不同生命周期之间有所区别(参见图3)。对于欧洲经委会的条例,生命周期是指车辆类型的生命周期,例如从开发到开始生产到停止生产。如果看一下ISO 26262]和SAE J3061,生命周期的重点是一个系统(元素,组件)的工程,可以在多个车辆中使用。对于车辆本身,有生产、使用和退役的生命周期。为了获得型号批准,例如,开始生产,OEM需要证明该组织和所有参与的供应商都有一个经过认证的CSMS。

图3.汽车领域的不同生命周期
这些流程需要确保安全问题得到充分考虑,并包括以下重点:
•组织中的网络安全管理
•对车辆类型风险的管理(识别、评估、归类和处理)
•验证对已识别风险的充分管理
•在开发和生产过程中的安全测试
•检测和应对针对车辆类型的网络攻击
•识别和管理新的网络威胁和车辆类型的脆弱性
•风险评估的更新
此外,汽车制造商必须确保所有流程在分布式开发环境中工作。
B.后期生产阶段
对生产后阶段的要求主要是对CSMS的要求进行细化,以确保网络安全被整合到车辆的生命周期中。车辆制造商必须证明如何在车辆生命周期内保持对法规的遵守和保护。这包括监测威胁状况和漏洞的变化。需要对已实施的安全措施的有效性进行监测。重点是确保不断变化的环境不会导致对安全和可用性的影响。为了确保这一点,需要建立事件响应程序。
C.车辆类型
只有当原始设备制造商和所有供应商的CSMS认证到位后,才能进行整车型式批准。整车型式批准的证据需要包括:
•在风险评估中如何考虑已知的漏洞和威胁。风险评估需要考虑整个车辆、所有车辆系统以及它们之间的相互作用。
•在风险评估中被确定为关键的要素,被设计成适当的安全措施,以使风险降低到可接受的水平。
要素包括:
–车辆架构和系统
–与网络安全有关的组件和系统
–与网络安全有关的部件和系统与其他车内和外部系统之间的相互作用
•从确定的风险到实施的缓解措施再到测试结果的追踪,以证明所有的风险都得到了充分的覆盖

如果车辆支持售后软件、服务、应用程序或数据的存储或执行,则需要有专门的受保护环境。所需要的信息需要通过整个供应链收集和验证。


III.汽车网络安全框架的技术现状

UNECE对CSMS的要求是一个完整的网络安全流程框架,涵盖了在整个车辆生命周期中与实现网络安全相关的所有活动。它必须涵盖所有可能影响网络安全的利益相关者。这个框架应该产生证据,证明为什么车辆的网络安全得以实现。
虽然这样的整体框架还不存在,但已经有了发展的起点。我们将在接下来的章节中概述a)汽车领域现有的网络安全流程和b)现有的保证方法。在这个过程中,必须在以下方面有所区别:
•在开发、生产和后期制作中管理网络安全的流程
•处理汽车领域的分布式性质的过程
第一套流程可以被概括为风险管理流程,第二部分可以被概括为汽车供应链管理。
A.汽车网络安全风险管理
ISO 31000中提出了通用的风险管理流程。风险管理被定义为一个反复的过程,它必须在整个生命周期中执行。NIST对组织和系统层面的风险管理进行了更详细的描述。这两种方法都在高层次上涵盖了CSMS风险管理的要求。
1)风险识别:汽车风险识别的一个著名方法是威胁建模。事实表明,威胁建模可以贯穿整个车辆生命周期,用于识别由于设计漏洞和潜在威胁造成的风险,甚至可以用来监测已部署系统的漏洞。最近的方法证明了威胁建模如何支持安全测试过程,也可以作为安全和保障的组合方法的一部分。威胁建模依赖于有关威胁和网络安全状况的最新知识,其中包括对整体威胁状况的监测,也包括对车辆的取证能力。
2)风险评估:对于风险评估,存在不同的方法,这些方法部分包含在风险识别方法中。一个成熟的方法是由评估攻击概率的通用标准来定义的。攻击概率可以根据现有的信息和生命周期阶段进行调整。这被用作EVITA项目的出发点。在HEAVENS项目中,收集了一套风险识别和评估方法并发表了报告。在CySiVuS项目中,开发了一个基于FAIR的统一的安全和保障的定量风险评估。
3)风险归类:风险分类目前仍是一个开放的话题。现有的方法是[19],它将威胁分为安全相关和非安全相关。在 [22] 提出了安全、财务、操作和隐私(SFOP)的分类。其他方法使用自动方法对风险进行分类。
4)风险处理:风险处理包括所有适合缓解和减少风险的措施,以及验证所应用措施有效性的必要步骤。深度防御策略是汽车领域的一个合适的出发点。在此基础上,风险处理的技术措施主要分为四个层次。
1)接口:现代汽车拥有广泛的接口,可以作为潜在的攻击面。我们的目标是尽量减少接口的数量,并确保所有的接口都受到保护。
2)网关:网关用于互联不同的总线系统,因此很适合放置额外的安全措施,以隔离网络部分和控制访问。
3)网络:汽车车辆使用多个内部通信系统,为各自的性能和安全要求量身定做。性能限制了密码学解决方案的适用性。由于机器对机器通信的预定性质,入侵检测系统是一个很好的方法。
4)控制单元:保护控制单元的大多数方法都使用基于硬件的安全性,以确保设备完整性、关键功能的隔离和启用受保护的存储。这些方法也可以用于篡改保护和确保安全引导。
风险管理的过程需要被整合到生命周期中,以确保在生命周期的正确阶段考虑风险识别、评估和分类,并确保以安全的方式实施风险处理措施。
5)过程:为了安全开发,最早的方法之一是SAE J3061,它基于ISO 26262定义的过程模型。ISO/SAE 21434是汽车系统网络安全工程标准的进一步发展,计划于2020年发布。
除了这些主要关注于整体工程过程的标准外,IEC 62443还适用于生产环境和NIST出版物,如用于密钥管理。另外,安全编码指导和如何使用基于硬件的安全指导也可以被整合。
B.汽车网络安全供应链管理
根据UNECE的要求,这里的供应链不仅包括汽车工业的分层结构,还包括售后市场。
对于汽车领域的互动,确保供应商的网络安全能力的方法可以基于现有的能力和评估方案。例如,OEM可以要求其供应商根据TISAX评估证明其系统的信息安全,以确保关键信息得到保护。一个受保护的生产环境可以通过基于IEC 62443的环境评估来证明。汽车SPICE评估,扩展了安全,也可用于评估流程。
对于责任和任务的分配,可以使用现有的安全的方法。开发界面协议(DIA)是为安全关键系统的分布式开发而开发的。类似的接口协议可以用来定义车辆生命周期不同阶段的责任。例如,监测不断变化的威胁和漏洞的责任可以由汽车制造商以外的组织来承担。我们看到像AUTO-ISAC这样的组织在这方面的初步做法。在这里,关于如何分享事件信息的方法也很重要。图4给出了不同类型的接口协议如何涵盖生命周期的不同阶段的例子。
图4. 生命周期中不同接口协议的例子
与汽车制造商没有合同关系的组织的管理更具挑战性。反向工程显示,许多目前可用的安卓汽车信息娱乐系统应用程序包括潜在的漏洞。这里的问题是,汽车制造商是否可以通过为第三方应用程序提供安全的执行环境来解决这个问题,或者除此之外,系统需要被限制,只允许由汽车制造商测试的应用程序。
一个类似的分析表明,当车辆在维修店访问时,诊断界面是一个潜在的风险因素。解决这个问题的一个建议是扩展的车辆概念。扩展的车辆概念包括由外部组织控制对车辆数据的访问,该组织根据实施情况充当数据交换中心或认证机构。这里的一个挑战是安全和控制访问与竞争法的规定之间的潜在冲突。
C.汽车网络安全保障
根据ISO/IEC/IEEE 15025-1的定义,保证是 "有理由相信一项要求已经或将要实现"。这是通过一个保证案例来完成的,该案例由一个系统的论证及其支持的证据和假设组成,以证明一个最高级别的要求已经实现。虽然ISO/IEC/IEEE 15025对保证案例的结构给出了数学定义,但GSN等图形符号也有好处。这两种方法都有一个挑战,那就是需要考虑网络安全不断发展的性质,例如,威胁者的能力在不断增强。

证据需要显示网络安全的完整性和充分性。完整性表明,根据目前的最先进的技术,所有的风险都得到了考虑。充分性表明,处理风险的方式是充分的。  完整性可以通过提供证据证明在整个生命周期内采用了系统的程序来证明。充分性的证据需要表明风险得到了充分的处理。这方面的保证要求可以从通用标准和NIST的测试指南中获取。提出的技术从文件审查开始,包括对已经使用的系统进行持续测试和评估的技术。对于网络安全保障来说,一个挑战是如何确定什么时候产生的证据是足够的。


IV.CSMS框架

正如前面几节所概述的,需要一个总体框架,涵盖完整的生命周期并整合开发和运营。我们提出了一种DevOps的方法,它适合于将开发、生产和运营的过程构建成一个一致的框架。提出的框架是基于Dobaj等人以前的工作,结构上分为两个主要部分,如图5所示:
1)第五代的车辆E/E架构,首先,能够将车辆系统连接到云系统,以便继续监测;其次,提供技术基础,以建立一个可以轻松更新和重新配置的模块化系统架构。
2)在模块化的E/E架构之上,可以建立一个DevOps生命周期,以实现持续的改进周期。
图5. 拟议的DevOps框架涵盖了从开发到生产再到运营的整个车辆生命周期
监控和分析过程是这个生命周期的核心特征,因为这些过程为检测开发和运行期间的故障和安全事件提供了基础。
如图5中的V型模型所示,拟议的DevOps框架与基于V型模型的传统系统开发流程是兼容的。无论是系统开发周期还是系统改进周期,都由同样的三个主要阶段组成:计划、创建/实施和验证与确认(V&V)。开发周期由业务需求触发,而改进周期则由监控和分析过程自动触发,只要在V&V阶段或车辆运行期间检测到故障或安全事件。
在成功的V&V阶段之后,在持续的质量阶段进行集成测试、故障注入测试和渗透测试,以保证系统的安全、保障和质量。在随后的发布阶段,代码签名和信息安全管理被应用,以提供一种措施来确保分布式软件部署过程中的系统完整性。在随后的预防阶段,安全由每辆车单独确保。异常情况会在本地进行分析,并传送到外部系统进行进一步调查。

每当车辆运行过程中检测到事故或故障,响应阶段就会转发一份报告。然后,该响应在预测阶段由人工处理和分析,或通过[50]中提出的自动推理机制进行处理和分析。获得的结果被转发到故障或事件库,这是CSMS的一部分。这个存储库在适应阶段经常被扫描,根据优先级标准,选择一个报告的故障或事件进行调查,从而触发下一个持续改进周期。


V.结论

本文提出了在汽车领域即将到来的网络安全法规的挑战,并确定了现有的构建模块。对于CSMS的整体结构,介绍了一种DevOps的方法。
公开的挑战是将构件映射到DevOps流程中,例如,对流程进行细化以包括方法和活动。此外,需要一个分布式的DevOps流程来考虑汽车领域的分层结构,而即将出台的法规不仅涉及网络安全,还涉及软件更新,需要通过质量认证。认证取决于保证,这需要考虑汽车工程的分布式性质和网络安全的演变性质。

参考文献:

[1]C. Ebert and C. Jones, “Embedded software: Facts, figures, and future.,”IEEE Computer, vol. 42, no. 4, 2009.

[2]European Commission, “A European strategy on Cooperative Intelligent Transport Systems, a milestone towards cooperative, connected and automated mobility,” 2016.

[3]Intel, “Safety First for Automated Driving,” 2019.

[4]S. Strobl, D. Hofbauer, C. Schmittner, S. Maksuti, M. Tauber, and J. Delsing, “Connected cars Threats, vulnerabilities and their impact,” in 2018 IEEE Industrial Cyber-Physical Systems (ICPS), (St. Petersburg), pp. 375–380, IEEE, 2018.

[5]M. Ring, J. Durrwang, F. Sommer, and R. Kriesten, “Survey on vehicular attacks - building a vulnerability database,” in 2015 IEEE International Conference on Vehicular Electronics and Safety (ICVES), (Yokohama), pp. 208–212, IEEE, 2015.

[6]Charlie Miller and Chris Valasek, “Remote Exploitation of an Unaltered Passenger Vehicle,” tech. rep., Black Hat 2015, 2015.

[7]Wikipedia, “World forum for harmonization of vehicle regulations.” https://w.wiki/8tP, (accessed 2019-09-07).

[8]UNECE,“TaskforceonCyberSecu- rityand(OTA)softwareupdates(CS/OTA).” https://wiki.unece.org/pages/viewpage.action?pageId=40829521, (accessed 2019-09-07).

[9]W. Kerber and D. Moeller, “Access to data in connected cars and the recent reform of the motor vehicle type approval regulation,” 2019.

[10]UNECE WP.29 GRVA,  “Draft recommendation on cyber security of  the task force on cyber security and over-the-air issues of unece wp.29 grva.” https://wiki.unece.org/pages/viewpage.action?pageId=60362218, 2018-09-21 (accessed 2019-09-07).

[11]UNECE   WP.29   GRVA,  “DGRVA-01-xx   (UN-CS  OTA)   Final Draft Recommendation on Software Updates incl. Annex A-B.” https://wiki.unece.org/pages/viewpage.action?pageId=60362218, 2018- 09-21 (accessed 2019-09-07).

[12]ISO/TC 22/SC 32, “ISO 26262 Road vehicles - Functional safety,” ISO

- International Standardization Organization, 2018.

[13]SAE Vehicle Electrical System Security Committee and others, “Sae j3061-cybersecurity guidebook for cyber-physical automotive systems,” SAE-Society of Automotive Engineers, 2016.

[14]ISO, “Risk management–principles and guidelines,” International Or- ganization for Standardization, Geneva, Switzerland, 2009.

[15]J. T. Force, “Risk management framework for information systems and organizations,” NIST Special Publication, vol. 800, p. 37, 2018.

[16]A. Karahasanovic, P. Kleberger, and M. Almgren, “Adapting threat modeling methods for the automotive industry,” in Proceedings of the 15th ESCAR Conference, pp. 1–10, 2017.

[17]Z. Ma and C. Schmittner, “Threat modeling for automotive security analysis,” Advanced Science and Technology Letters, vol. 139, pp. 333– 339, 2016.

[18]M. Wolf, “Combining safety and security threat modeling to improve automotive penetration testing,” 2019.

[19]G. Macher, H. Sporer, R. Berlach, E. Armengaud, and C. Kreiner, “Sahara: a security-aware hazard and risk analysis method,” in Pro- ceedings of the 2015 Design, Automation & Test in Europe Conference & Exhibition, pp. 621–624, EDA Consortium, 2015.

[20]C. Schmittner, Z. Ma, and P. Smith, “Fmvea for safety and security anal- ysis of intelligent and cooperative vehicles,” in International Conference on Computer Safety, Reliability, and Security, pp. 282–288, Springer, 2014.

[21]“Common Methodology for Information Technology Security Evalua- tion - Evaluation methodology,” Sept. 2012.

[22]A. Ruddle, D. Ward, B. Weyl, S. Idrees, Y. Roudier, M. Friedewald,

T.  Leimbach,  A.  Fuchs,  S.  Gu¨rgens,  O.  Henniger,  et  al.,  “Deliverable d2.3: Security requirements for automotive on-board networks based on dark-side scenarios,” 2009.

[23]D. Dominic, S. Chhawri, R. M. Eustice, D. Ma, and A. Weimerskirch, “Risk assessment for cooperative automated driving,” in Proceedings   of the 2nd ACM Workshop on Cyber-Physical Systems Security and Privacy, pp. 47–58, ACM, 2016.

[24]M.  Islam,  C.  Sandberg,  A.  Bokesand,  T.   Olovsson,  H.  Broberg,P.  Kleberger,  A.  Lautenbach,  A.  Hansson,  A.  So¨derberg-Rivkin,  and S. Kadhirvelan, “Deliverable d2-security models,” HEAVENS Project, Deliverable D, vol. 2, 2014.

[25]T. Vogt, “Tool-chain enriched security development in automotive indus- try.” Presentation at the 12th Graz Symposium Virtual Vehicle (GSVF), 05 2019.

[26]B. Sheehan, F. Murphy, M. Mullins, and C. Ryan, “Connected and autonomous vehicles: A cyber-risk classification framework,” Trans- portation Research Part A: Policy and Practice, vol. 124, pp. 523–536, 2019.

[27]Information Assurance Solutions Group, “Defense in depth.pdf,” 2010.

[28]Andy Birnie and Timo van Roermund, “A multi-layer vehicle security framework,” 2016.

[29]F. Sagstetter, M. Lukasiewycz, S. Steinhorst, M. Wolf, A. Bouard, W. R. Harris, S. Jha, T. Peyrin, A. Poschmann, and S. Chakraborty, “Security challenges in automotive hardware/software architecture design,” in Proceedings of the Conference on Design, Automation and Test in Europe, pp. 458–463, EDA Consortium, 2013.

[30]M. Wolf, A. Weimerskirch, and C. Paar, “Security in automotive bus systems,” in Workshop on Embedded Security in Cars, Bochum, 2004.

[31]S.-F. Lokman, A. T. Othman, and M.-H. Abu-Bakar, “Intrusion detection system for automotive controller area network (can) bus system: a review,” EURASIP Journal on Wireless Communications and Networking, vol. 2019, no. 1, p. 184, 2019.

[32]L. Chen, J. Franklin, and A. Regenscheid, “Guidelines on hardware- rooted security in mobile devices,” tech. rep., National Institute of Standards and Technology, 2012.

[33]A. Barber, “Status of work in process on iso/sae 21434 automotive cybersecurity standard,” presentation, ISO SAE International, vol. 10, 2018.

[34]C. Schmittner, G. Griessnig, and Z. Ma, “Status of the development of iso/sae 21434,” in European Conference on Software Process Improve- ment, pp. 504–513, Springer, 2018.

[35]IEC, “Iec 62443 - security for industrial automation and control sys- tems,” International Electrotechnical Commission, 2018.

[36]E. Barker and W. Barker, “Recommendation for key management, part 2: Best practices for key management organizations (2nd draft),” tech. rep., National Institute of Standards and Technology, 2018.

[37]M. Broy, I. H. Kruger, A. Pretschner, and C. Salzmann, “Engineering automotive software,” Proceedings of the IEEE, vol. 95, no. 2, pp. 356– 373, 2007.

[38]O.-S. Goia et al., “Tisax assessment for information security in the automotive industry,” 2019.

[39]ISO, “Information technology security techniques information security management systems requirements,” International Organization for Standardization, Geneva, Switzerland, 2013.

[40]G. Macher, A. Much, A. Riel, R. Messnarz, and C. Kreiner, “Automotive spice, safety and cybersecurity integration,” 09 2017.

[41]A. ISAC, “Automotive information sharing and analysis center.” https://www.automotiveisac.com/, (accessed 2019-09-23).

[42]C. Johnson, M. Badger, D. Waltermire, J. Snyder, and C. Skorupka, “Guide to cyber threat information sharing,” tech. rep., National Institute of Standards and Technology, 2016.

[43]A. K. Mandal, A. Cortesi, P. Ferrara, F. Panarotto, and F. Spoto, “Vulner- ability analysis of android auto infotainment apps,” in Proceedings of the 15th ACM International Conference on Computing Frontiers, pp. 183– 190, ACM, 2018.

[44]P. Kleberger, T.  Olovsson, and E. Jonsson, “An  in-depth analysis of  the security of the connected repair shop,” in The Seventh International Conference on Systems and Networks Communications (ICSNC), Pro- ceedings. Lisbon, 18-23 November, 2012. IARIA., p. 99, 2012.

[45]E. A. M. A. ACEA, “Safe and secure access to vehicle data.” https://cardatafacts.eu/, (accessed 2019-09-23).

[46]M. McCarthy, M. Seidl, S. Mohan, J. Hopkin, A. Stevens, and F. Og- nissanto, “Access to in-vehicle data and resources,” 2017.

[47]I.   ISO,   IEC,    “Systems    and    software    engineering    systems and software assurance part 1: Concepts and vocabulary.” ”https://www.iso.org/obp/ui/iso:std:73567:en”, 2019.

[48]T. Kelly and R. Weaver, “The goal structuring notation–a safety argu- ment notation,” in Proceedings of the dependable systems and networks 2004 workshop on assurance cases, p. 6, Citeseer, 2004.

[49]K. Scarfone, M. Souppaya, A. Cody, and A. Orebaugh, “Technical guide to information security testing and assessment,” NIST Special Publication, vol. 800, no. 115, pp. 2–25, 2008.

[50]J. Dobaj, J. Iber, M. Krisper, and C. Kreiner, “Towards Executable Dependability Properties,” 2018.

[51]J. Dobaj, M. Krisper, and G. Macher, “Towards Cyber-Physical Infras- tructure as-a-Service (CPIaaS) in the Era of Industry 4.0,” 2019.

[52]W. Haas and P. Langjahr, “Cross-domain vehicle control units in modern E/E architectures,” 2016.

END

分享不易,恳请点个【👍】和【在看】

智能汽车开发者平台 分享汽车最新前言技术解读,行业分析,与授权行业资料分享平台。
评论
  •        很多人只见过封装在SMD外壳里的小尺寸晶振,却不知道一颗2016、1612甚至1210封装的微型石英晶振,从一块巴掌大的石英原矿,到最终能稳定起振的成品,要经过十几道精密工序。它内部的石英晶片厚度最薄不到20微米,比普通A4纸的1/5还薄,整个生产过程里哪怕0.1微米的误差,都会直接废掉整批产品,这也是小尺寸晶振过去长期依赖进口,国内厂商花了十几年才啃下量产硬骨头的核心原因。1. 原石定向切割:0.01度的角度误差都不能有小尺寸晶振的第一步,
    TKD泰晶科技 2026-08-07 08:43 374浏览
  • 做蓝牙音箱的工程师大概都碰过这个局面。产品要连手机放歌,要本地播开机提示音和按键音,还要接 App 做配网和状态上报。三件事拆开,早先的常规做法是音频蓝牙一颗料、数传蓝牙一颗料、本地播放再挂一颗小 MCU 加一片 Flash。板子越画越大,BOM 越算越贵,待机电流和固件工作量也跟着涨。WT2605C 出来以后,这套需求可以集成到一颗芯片,就是 WT2605C-32N,该芯片采用QFN32 封装,4×4 毫米,把音频蓝牙、BLE 数传和 MP3 本地播放三样全包了。对蓝牙音箱来说,最实在的好处就
    唯创知音语音芯片 2026-08-06 15:14 284浏览
  • ​摘要:低价大流量卡正全面退市,政策收紧已成定局。面对传统号卡的不确定性,随身WiFi凭借稳定连接、多设备共享、独立设备和灵活套餐等优势,成为务实可靠的备选方案。1、流量卡黄金时代要结束了通信行业正迎来一场前所未有的“地震式”调整——曾让无数用户追捧的低价大流量卡,正在全速退出各大平台。这早已不是一次普通的竞合,而是一场趋势性的行业洗牌。回望过去,19元200G的神卡,那时真是“睡着都能笑醒”,便宜到不敢相信,爽到忍不住炫耀。那些日子,好像随便刷、随便看,流量自由触手可及。可如今,回头再看,那种
    爱上电路设计 2026-08-03 10:21 128869浏览
  • 智能宠物用品这几年快速普及,自动清理几乎成了智能猫砂盆的标配。猫咪用完离场,设备自动翻转清理,养宠家庭省去了每天弯腰清理的麻烦。但自动清理的第一步,是先准确判断猫到底在不在盆里。这个看似简单的问题,在小空间里并不容易做好。近场检测的痛点:距离太远反而误事猫砂盆内部空间有限。如果传感器的检测距离设得偏大,盆外路过的猫、人甚至物品都会被误判为猫在盆内,结果该清理时不清理、不该清理时乱清理,体验直接崩坏。这类产品的核心诉求其实就一句话:近距离、小范围、精准识别,不能有半点误判。常规感应方案常因检测距离
    唯创知音语音芯片 2026-07-31 16:51 306浏览
  •     长期专注WiFi领域,也算是行业老兵了!同行闲聊中,时不时能提起我和我们!从疫情起,国产替代风生水起,起起落落,大浪淘沙,生存下来的都是强者!    WiFi模块应用广泛,对于高端市场和特定市场,要求WIFI模块需要过CE/FCC之类的认证,也就是说没有认证的模块,不具备导入产品设计.接下来就和大家聊聊认证模块选型参考!    WIFi模块硬件方面主要考虑以下九点特性:    1
    纳拓科技 2026-07-31 17:56 252浏览
  • 导语在现代高速数字电路设计中,信号的完整性已不仅是理想波形推演,而是一场与物理非理想特性正面博弈的工程实践。滤波器芯片作为净化传输链路的关键屏障,其核心挑战在于:能否有效识别并滤除那些隐匿在电平跳变过程中的亚纳秒级瞬态脉冲干扰,这类干扰持续极短,却足以在高速链路中引发误触发。然而,传统函数发生器受限于采样率与边沿速率,根本无法忠实复现如此狭窄且陡峭的异常波形。针对此困境,德思特TS-AWG7000系列任意波形发生器以17 GS/s采样率与50 ps原生边沿速度,为瞬态脉冲提供精细刻画,配合SPG
    德思特测试测量 2026-08-05 14:06 5浏览
  • 摘要在防爆电气设计中,只参照芯数选型而忽略额定载流量,长期满负荷运行会出现插头发热、接触面氧化、IP67 密封受热老化等问题。结合常用 3 针 3 孔、4 芯、5PIN、8PIN 圆形防爆连接器,制作分级电流参数对照表,区分冷压免焊接、焊接两种接线结构的安全载流数值,设置合理电流冗余系数,搭配使用环境修正参数,规范防爆接近开关连接器、防爆法兰插座的选型计算方式。关键词圆形防爆连接器,载流参数表,防爆法兰插座,防爆端子接头,IP67 防爆防水接插件1 产品概述圆形防爆连接器触点载流能力由插针直径、
    kyfbest科迎法电气 2026-08-03 09:18 128642浏览
  • 摘要防爆自控系统同时布设本安信号、工业总线、动力供电三类线路,仅依靠标识标牌管控插接极易出现人为错插问题,高压动力回路窜入本安弱电回路会突破安全栅限能标准,产生点火风险。依托 A、D、K 标准化机械防呆编码体系,搭配护套颜色区分管理,适配 3 针 3 孔免焊接冷压增安型防爆航插、5PIN 总线防爆航空插头、8 芯焊接防爆法兰插座的选型使用,从物理结构层面杜绝防爆接近开关连接器、防爆传感器航插接头混用插接问题,补齐防爆系统被动安全防护体系。关键词圆形防爆连接器,防呆编码防爆航插,防爆航空插头,防爆
    kyfbest科迎法电气 2026-07-31 18:29 407浏览
  • 在芯片总成本中占比不到 1%,却可能因一处品质偏差导致整片晶圆报废——半导体切割/研磨胶带,正随着先进封装的爆发,成为封测产线选型中最谨慎对待的耗材之一。但鲜有人注意到,决定这层胶带性能上限的,是上游一层更薄的基膜。这个长期由日本企业主导的隐形环节,正在出现国产突围的信号。一、需求之变:先进封装与“韬定律”重塑胶带市场AI 算力芯片、HBM 高带宽存储、Chiplet 芯粒等先进封装产品持续放量,国内封测产线扩产节奏不减。作为晶圆减薄与切割工序的必需耗材,晶圆胶带的需求同步扩容。据 QYRese
    芯膜前沿 2026-07-31 16:35 372浏览
  • 在EMC测试过程中,传导发射(Conducted Emission,CE)超标是工程师最常遇到的问题之一。更令人头疼的是,同样的超标曲线背后,可能对应着完全不同的干扰机理:有的是差模噪声沿电源回路传播,有的是共模电流通过寄生路径耦合,还有些问题甚至并非来自电源本身,而是负载、电缆布局或接地结构引起的连锁反应。 · 150kHz~1MHz 超标:多为差模噪声为主,干扰沿火线-零线回路传输。 · 1MHz~30MHz 超标:通常共模噪声占主导,干扰通过火线/零线对地回路传播。 如果条件允许,用电流探
    誉磁电磁兼容EMC 2026-07-31 18:45 501浏览
  •                                                                        
    广州铁金刚 2026-08-06 17:44 100322浏览
  • 产品使用18V供电,配套4串锂离子电池,需要设计一个充电器。因为输入18V,电池最高 16.8V,压差仅 1.2V。因为压差太小。使用开关型的充电控制芯片不稳定。尝试自行设计一个。整体采用分立三极管 + TL431架构,分4个功能单元:使能控制回路、限流环路、TL431 精密恒压反馈环路、PNP 功率管主功率输出回路;实现完整锂电池充电逻辑。使能控制回路按键按下:5V 电压经 R12 (2kΩ) 送入 NPN 管 Q3 基极,Q3 饱和导通,对地拉低 R1、R2 组成的分压控制节点电位;该节点直
    southcreek 2026-08-07 13:45 316浏览
  • 在物联网从“万物互联”迈向“万物智联”的进程中,LTE Cat.1凭借其在速率、成本与网络覆盖之间的完美平衡,正成为中低速物联网市场的绝对主力。随着2G/3G网络的逐步退网以及新国标对终端设备智能化、定位功能的强制要求,Cat.1模组迎来了爆发式的增长窗口。在这一关键节点,基于华为海思Hi2131芯片设计的LTE Cat.1模组,凭借其在能效、射频、架构及物理规格上的底层创新,成功打破了“高性能必高功耗”的传统魔咒,为行业提供了极具竞争力的连接最优解。核心技术优势:重塑Cat.1能效与连接标杆海
    用户1778981989717 2026-08-05 21:04 169浏览
  • 在前六期中,我们已经分别讨论了 CRA 的适用范围、整体影响、漏洞通报义务、风险评估与技术文档证据链、第三方组件与 SBOM 供应链治理,以及产品上市后的支持期、安全更新、用户说明和终止支持管理。到这里,企业已经能够回答几个核心问题:产品是否落入 CRA 适用范围,产品由哪些组件构成,企业如何证明自己在设计、开发和上市前采取了必要的安全措施,以及产品上市后如何持续维护和安全下线。但对于真正准备落地 CRA 合规的企业来说,还有一个更现实的问题:CRA 的法规条文相对原则化,企业应当如何把“网络安
    虹科云科技 2026-08-03 16:51 149218浏览
  • 文:杜杰编辑:侯煜当地时间7月28日,美国特朗普政府落地最新科技封锁政策,美国联邦通信委员会(FCC)正式更新《受管制清单》,新增两大类设备——境外生产的先进机器人设备、境外生产的联网电力逆变器。FCC在官方情况说明书中明确,该类境外制造产品,“会对美国国家安全或美国民众的人身安全构成无法承受的风险”。本次新规设置明确豁免机制:经美国国防部(DoW)、电力逆变器品类经美国国土安全部(DHS)审核并授予“有条件批准”,认定对应设备品类不存在重大安全风险,即可获得准入豁免。同时政策严格执行新老划断原
    华尔街科技眼 2026-08-03 21:28 325浏览
我要评论
0
点击右上角,分享到朋友圈 我知道啦
请使用浏览器分享功能 我知道啦