AI-based classification of CAN measurements for network and ECU identification

Ralf Lutchen, Andreas Krätschmer, Hans Christian Reuss
{"title":"AI-based classification of CAN measurements for network and ECU identification","authors":"Ralf Lutchen,&nbsp;Andreas Krätschmer,&nbsp;Hans Christian Reuss","doi":"10.1007/s41104-022-00116-6","DOIUrl":null,"url":null,"abstract":"<div><p>Due to the constantly increasing number of functions offered by a modern vehicle, the complexity of vehicle development is also increasing as a result. A first indication of this connection is provided by the number of ECUs (electronic control units) used in current development vehicles. Furthermore, each ECU also performs more functions and is not only electrically networked with the other ECUs, but also logically and functionally. On this basis, new cooperative functions are being developed, which are used for example for autonomous driving. In vehicle development, more and more test sequences (diagnostic scripts) are established for function testing of individual components, systems and cross-functional methods. Due to decentralization and the modular approach, modern development vehicles consist of different numbers of ECUs. The high number of ECUs in purpose and number poses a challenge for test creation and updating. The ECU software is also developed in cycles within the vehicle cycle. This results in a very high software variance. This variance leads to the fact that in the vehicle development with global test conditions works. Global test conditions at this point mean that more ECUs are included in the measurement procedure than are installed in the vehicle. The vehicle structure (control unit and its software version) is not known to the person performing the measurement. He relies on the fact that his ECUs are inside in the global measurement task. This means that the vehicle network architecture is uncertain, which can lead to errors during test execution. Since the ECUs that are actually installed in the vehicle are first determined during test execution, this results in a longer script runtime than would be necessary. To support the development engineer and prevent avoidable errors, the diagnostic system should configure itself as far as possible. This means that individually customized measurements for each vehicle should be calculated in the cloud and not the global measurement tasks. For a diagnostic system to be able to configure itself independently, the vehicle network structure must be determined in a first step. This can be done by a simple CAN measurement (measurementXY.asc). An AI is able to analyze this measurement and classify the occurring ECUs as well as CAN networks. For larger measuring devices with more than one CAN interface, the user who analyzes the measurement is interested in which CAN was connected. Here, the AI is suitable to determine the name of the network and the communicating ECUs based on the communication that runs over the bus. For this purpose, the AI classifies the number of communicating ECUs based on the time intervals at which messages are sent. In addition, the AI can be supported by a special diagnostic script (global.pattern) to determine the vehicle structure at the OBD (on-board diagnostics) interface with maximum accuracy. Three AI approaches are presented, all connected in series and passing results to each other (pipeline mode). First comes the AI that separates vehicle communication from diagnostic communication. Based on the vehicle communication, the network name can be determined. Based on the diagnostic messages, the ECUs can be determined.</p></div>","PeriodicalId":100150,"journal":{"name":"Automotive and Engine Technology","volume":"7 3-4","pages":"317 - 330"},"PeriodicalIF":0.0000,"publicationDate":"2022-08-26","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"https://link.springer.com/content/pdf/10.1007/s41104-022-00116-6.pdf","citationCount":"0","resultStr":null,"platform":"Semanticscholar","paperid":null,"PeriodicalName":"Automotive and Engine Technology","FirstCategoryId":"1085","ListUrlMain":"https://link.springer.com/article/10.1007/s41104-022-00116-6","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
引用次数: 0

Abstract

Due to the constantly increasing number of functions offered by a modern vehicle, the complexity of vehicle development is also increasing as a result. A first indication of this connection is provided by the number of ECUs (electronic control units) used in current development vehicles. Furthermore, each ECU also performs more functions and is not only electrically networked with the other ECUs, but also logically and functionally. On this basis, new cooperative functions are being developed, which are used for example for autonomous driving. In vehicle development, more and more test sequences (diagnostic scripts) are established for function testing of individual components, systems and cross-functional methods. Due to decentralization and the modular approach, modern development vehicles consist of different numbers of ECUs. The high number of ECUs in purpose and number poses a challenge for test creation and updating. The ECU software is also developed in cycles within the vehicle cycle. This results in a very high software variance. This variance leads to the fact that in the vehicle development with global test conditions works. Global test conditions at this point mean that more ECUs are included in the measurement procedure than are installed in the vehicle. The vehicle structure (control unit and its software version) is not known to the person performing the measurement. He relies on the fact that his ECUs are inside in the global measurement task. This means that the vehicle network architecture is uncertain, which can lead to errors during test execution. Since the ECUs that are actually installed in the vehicle are first determined during test execution, this results in a longer script runtime than would be necessary. To support the development engineer and prevent avoidable errors, the diagnostic system should configure itself as far as possible. This means that individually customized measurements for each vehicle should be calculated in the cloud and not the global measurement tasks. For a diagnostic system to be able to configure itself independently, the vehicle network structure must be determined in a first step. This can be done by a simple CAN measurement (measurementXY.asc). An AI is able to analyze this measurement and classify the occurring ECUs as well as CAN networks. For larger measuring devices with more than one CAN interface, the user who analyzes the measurement is interested in which CAN was connected. Here, the AI is suitable to determine the name of the network and the communicating ECUs based on the communication that runs over the bus. For this purpose, the AI classifies the number of communicating ECUs based on the time intervals at which messages are sent. In addition, the AI can be supported by a special diagnostic script (global.pattern) to determine the vehicle structure at the OBD (on-board diagnostics) interface with maximum accuracy. Three AI approaches are presented, all connected in series and passing results to each other (pipeline mode). First comes the AI that separates vehicle communication from diagnostic communication. Based on the vehicle communication, the network name can be determined. Based on the diagnostic messages, the ECUs can be determined.

查看原文
分享 分享
微信好友 朋友圈 QQ好友 复制链接
本刊更多论文
基于AI的CAN测量分类用于网络和ECU识别
由于现代车辆提供的功能数量不断增加,因此车辆开发的复杂性也在增加。这种连接的第一个指示是由当前开发车辆中使用的ECU(电子控制单元)的数量提供的。此外,每个ECU还执行更多的功能,并且不仅与其他ECU电气联网,而且在逻辑和功能上也是如此。在此基础上,正在开发新的协作功能,例如用于自动驾驶。在车辆开发中,建立了越来越多的测试序列(诊断脚本),用于单个部件、系统和跨功能方法的功能测试。由于分散化和模块化方法,现代开发工具由不同数量的ECU组成。ECU在目的和数量上的高数量对测试创建和更新提出了挑战。ECU软件也是在车辆循环中的循环中开发的。这导致了非常高的软件差异。这种差异导致了这样一个事实,即在全球测试条件下的车辆开发是可行的。此时的全局测试条件意味着测量程序中包含的ECU比安装在车辆中的ECU更多。进行测量的人员不知道车辆结构(控制单元及其软件版本)。他依赖于这样一个事实,即他的ECU在全球测量任务中处于内部。这意味着车辆网络架构是不确定的,这可能导致测试执行过程中的错误。由于实际安装在车辆中的ECU是在测试执行期间首先确定的,因此这会导致脚本运行时间比所需时间更长。为了支持开发工程师并防止可避免的错误,诊断系统应尽可能自我配置。这意味着每个车辆的单独定制测量值应该在云中计算,而不是在全局测量任务中计算。为了使诊断系统能够独立配置自身,必须在第一步中确定车辆网络结构。这可以通过一个简单的can测量(measurementXY.asc)来完成。AI能够分析该测量并对发生的ECU以及can网络进行分类。对于具有多个CAN接口的大型测量设备,分析测量的用户对连接的CAN感兴趣。这里,AI适合于基于在总线上运行的通信来确定网络和通信ECU的名称。为此,AI根据发送消息的时间间隔对通信ECU的数量进行分类。此外,人工智能可以由一个特殊的诊断脚本(global.pattern)支持,以最大限度地准确地确定OBD(车载诊断)接口处的车辆结构。提出了三种人工智能方法,它们都是串联的,并相互传递结果(流水线模式)。首先是将车辆通信与诊断通信分离的人工智能。基于车辆通信,可以确定网络名称。基于诊断消息,可以确定ECU。
本文章由计算机程序翻译,如有差异,请以英文原文为准。
求助全文
约1分钟内获得全文 去求助
来源期刊
自引率
0.00%
发文量
0
期刊最新文献
Development of an electrochemically approximated simulation model and a hardware substitution cell approach for thermal management battery system tests A detailed comparison of ethanol–diesel direct fuel blending to conventional ethanol–diesel dual-fuel combustion Influence of the air–fuel-ratio and fuel on the reactivity of diesel soot Introducing the double validation metric for radar sensor models Chassis concept of the individually steerable five-link suspension: a novel approach to maximize the road wheel angle to improve vehicle agility
×
引用
GB/T 7714-2015
复制
MLA
复制
APA
复制
导出至
BibTeX EndNote RefMan NoteFirst NoteExpress
×
×
提示
您的信息不完整,为了账户安全,请先补充。
现在去补充
×
提示
您因"违规操作"
具体请查看互助需知
我知道了
×
提示
现在去查看 取消
×
提示
确定
0
微信
客服QQ
Book学术公众号 扫码关注我们
反馈
×
意见反馈
请填写您的意见或建议
请填写您的手机或邮箱
已复制链接
已复制链接
快去分享给好友吧!
我知道了
×
扫码分享
扫码分享
Book学术官方微信
Book学术文献互助
Book学术文献互助群
群 号:481959085
Book学术
文献互助 智能选刊 最新文献 互助须知 联系我们:info@booksci.cn
Book学术提供免费学术资源搜索服务,方便国内外学者检索中英文文献。致力于提供最便捷和优质的服务体验。
Copyright © 2023 Book学术 All rights reserved.
ghs 京公网安备 11010802042870号 京ICP备2023020795号-1