Steering-by-wire design method based on autonomous driving requirements
Latest update time：2022-10-30
Reads：
This article mainly shares five aspects:
-
Lateral control requirements for autonomous driving
-
Steer-by-wire software architecture
-
Mutual diagnosis and arbitration of redundant systems
-
Road sense collaborative control
-
Testing and evaluation of steer-by-wire
1. Lateral control requirements for autonomous driving
The lateral control requirements of autonomous driving are somewhat different from those of traditional actuators. In the actual process, such as steering or braking, many current domestic R&D are reverse development, or development based on the current state, lacking a forward development concept. All executive components and wire-controlled components are to satisfy the driver. Or vehicle motion control needs.
Therefore, there must be a positive thinking method when designing steering, not to edit the MAC verification method, but to design the control-by-wire components based on the needs of the driver and the needs of autonomous driving. Therefore, you must first know what autonomous driving requires the chassis to do, or what operations the driver requires the chassis to do.
At present, the development of steering is basically divided into two levels. One is electric power steering EPS less than or equal to L2, but in addition to the original auxiliary power steering system, EPS also adds some wire-controlled interface commands. There is also a steering-by-wire system that is greater than or equal to L3. It has its own characteristics at this stage. If it is less than or equal to L2, the main functional safety will be turned off when it fails, which is a fail off. For states greater than or equal to L3, fail-operation is required, that is, it can guarantee a certain function or degrade the function when it fails, and basically has the steering function. This is a very important critical point.
Software-Defined Chassis
In order to realize the above functions, various technologies have been proposed. First of all, we must have a positive thinking. Autonomous driving has certain requirements for chassis. The software-defined chassis on the left was proposed by our research institute and Qingche Zhixing. Defining the software chassis needs to be based on the needs of autonomous driving or the need to move the chassis independently. In the future, the development of complete vehicles may be chassis plus cockpit, that is, three domains and two platforms. The three domains support autonomous driving, smart cockpit domain and wire-controlled chassis domain; the two platforms are two hardware platforms: smart cockpit and smart chassis. As the shapes of smart cockpits continue to change, we must first define various cockpit shapes, that is, the stability of various cockpits is an indicator to be defined.
Only under this indicator, we can consider the planning instructions for autonomous driving and define what the current state of the vehicle is, whether it is a stable state, an unstable state, or a critical stable state, that is, the safety level prediction model. After the model is defined, we can maximize the to ensure that horizontal and vertical coordination is actually implemented.
After the horizontal and vertical coordination instructions are released, there are still software definitions to define the software and hardware decoupling of the execution system, because the chassis domain is a large computing platform and algorithm center, and the underlying steering, braking, and even suspension and drive-related application layer algorithms are all It can be continuously iterated on the platform, so it is necessary to decouple the execution system wire control and system software and hardware, and then define instructions related to horizontal and vertical coordination. At the same time, the software-defined chassis can also define extended functions of autonomous driving. This is the need for software-customized chassis.
Based on chassis domain control greater than or equal to L3, our research institute has implemented related architectures involving security level prediction, dynamic control, and software and hardware decoupling. The wire-by-wire execution system on the right puts forward different requirements for meeting chassis control requirements and vehicle requirements, especially for steering redundancy design and functional safety, including high-level road feel experience requirements, and later independent steering-related functional requirements.
In terms of technical route, it is from software-defined chassis to domain to execution components. In the actual production process, the product needs to be implemented, and it has to be worked backwards based on the execution components to meet the level-by-level technical requirements. This It’s a software-defined chassis.
Autonomous driving classification
As autonomous driving and driver assistance systems continue to mature, the classification of autonomous driving has undergone several rounds of optimization. The latest version of SAE driving automation level is very concerned about how to implement L3. Last year, when SAE made it clear that L3 must be driven by a human when a function is requested. If the entire vehicle does not request it, if a safety accident or other danger occurs to the entire vehicle, the responsibility lies with the entire vehicle; Once a feature request is released, someone must directly take over it. Each company has different views on how to implement the time delay. In terms of safety risk prediction, when a function is requested, there must be a certain buffer time for the driver to perform related operations, because theoretically, L3 can take hands off the steering wheel, feet off the brake pedal, and even read mobile phones/newspapers for a short time. When the vehicle has safety risks that it cannot overcome, the driver must take over the request.
In the process of continuous practice, the buffer time must be continuously optimized and updated. It is mainly the time for safety or risk prediction, or the time for early response. Therefore, L3 is also a very tangled stage. Some people even think that it should be 2.99 or skip L3 directly. But L3 is still an inevitable process in the short term, so a lot of steering-based research is between L3 and L2 or between L3. Direct switching between automatic driving and manual driving in L3 is a big test. Switching between automatic driving and manual driving How Switch Ramp is handled is important.
When it comes to L4 and L5, there are also some typical states. L4 still has a steering wheel, but it is in a completely decoupled state. The L5 steering wheel no longer exists. For steering, each mainstream R&D goal and R&D path is also different. There are two types in Europe. One is to cancel the steering wheel at L4 and replace it with a driving terminal, that is, an operating handle for emergency switching. Some still retain the steering wheel. The design ideas are different, so at the current stage, L3 and L3 have to be considered. Switch Ramp issue between L2.
Horizontal control development trends
What is horizontal development? If we consider the chassis control level of autonomous driving, there may be three-axis directional control in the future, that is, three-way control of lateral, longitudinal and vertical directions. Steering is the most important operation in lateral control, including automatic steering, so lateral control is a later development. important level of control.
The automotive industry is developing toward electrification, intelligence, and networking. Software-defined cars have been promoted. Domain control electronic and electrical architecture has continued to develop rapidly from distributed to domain control, to centralized domain, and even to the central computer approach in the later period. As a key lateral control mechanism, the steering system is the direction of future development.
The future transfer system will have several requirements. One is road feel simulation and performance requirements. The L3 to L4 stage is a very important stage. At this time, there is also a steering wheel, and it is a completely decoupled steering wheel. At this time, there will be some requirements. For example, weak vibration and noise reduction, variable steering ratio, and motion control all need to be reflected in road feel simulation and performance requirements.
The requirements for drive-by-wire chassis include flexible arrangement of steering and steering wheels, combined design based on chassis domains, and cross-platform applications. From the perspective of safety and reliability, there are fail-operationl (failure to operate), redundant architecture and functional safety. In terms of autonomous driving, the conversion between L2 and L3 involves angle control and steering wheel silence/folding.
Autonomous driving level requirements for steering
Autonomous driving's demand for steering is completely based on the current level of autonomous driving, and it puts forward requirements for steering characteristics. First, it is from conventional level 0 to level 1 and level 2, focusing on the driver and driver system. Conventional electric steering uses a simple three-phase motor, an independent power supply, a position sensor and a controller with one or two cores. It does not necessarily have heterogeneous redundancy, because the state below L2 is fail off. Once a danger or failure occurs, it will Turn off.
In terms of functional safety level, the dual-core function is required, especially when it cannot be turned off, the ASIL D safety level must be achieved, that is, it must be turned off when it must be turned off. Quadrant protection is also to meet ASIL D. When phase short circuit or motor short circuit occurs, it can be shut down in time to ensure related communication, network security and mechanical coupling status.
There will be big changes to L3. The driving body is responsible for the system, and the entire EPS design, that is, the steering-by-wire design, is a redundant EPS actuator design. The steering system has crossed over to steer-by-wire. Its two parts are road sense simulation and steering braking control or steering execution. It requires a six-phase motor or dual motor configuration, using dual power supplies, dual TAS backup, and three cores. Of course, It can be two functional cores, plus a lockstep core to ensure functional safety level and safe implementation.
When the safety level reaches ASIL D, it is necessary to have heterogeneous redundancy measures, expected functional safety factor analysis, quadrant protection, multiple communication modes, and hardware safety module modules to ensure relevant communication. At this time, mechanical coupling is cancelled, but And the steering wheel.
到L4、L5，方向盘是可屏蔽状态，甚至采用一些控制终端去实施。欧洲有两种声音，一是方向盘，二是终端，但美系和日韩系还是偏向于用方向盘，不希望用终端方式。
底层执行机构软件定义集成控制
作为一个大的运算中心和算法平台，底盘域是可以不断地OTA迭代的芯片平台，很多算法会上移。转向系统会将应用层在1或2毫秒层面直接进行算法上移。转向系统以后只会保留电机控制、机械系统和转向电机，特别是电机诊断实时系统，而应用算法都在底盘域中，所以给转向行业的工程师提出了更高要求，需要具备软件的软实力和机构不可替代的硬实力。以后的商业模式将转向系统厂商提供一套硬件系统，再加上打包的一套软件系统，直接给整车厂或Tire 1进行集成。
如何在这个过程中保证软件附加值，是从事转向行业的人需要考虑的事情。同样，制动也是这样，要增强软实力和硬实力，有自己独有的控制算法和一些专利保护，这些都会体现在后期的软件附加值中。
底盘控制软件协调控制封装组件
底盘域封装组件和转向相关的算法包括：前后轮协调转向控制、主动转向前后轮独立运算控制算法和线控转向路感模拟，这三块是软在底盘域中要上传到封装组件中。
线控转向软件组件
在AUTOSAR架构中，线控转向软件组件是SWC层面的软件组件，每一个软件组件都有相关功能描述，比如以正向思维设计转向功能，驾驶员转向自动驾驶、辅助系统功能，如车道保持，需要相关的扭矩接口、力矩接口或横向齿条力接口，通过转向驾驶控制模块、线控转向或EPS实现相应功能。
这个模块分成三部分，一是基础转向，侧重人驾驶的力矩控制，因为不管是L2还是L3都有方向盘，涉及基础助力，只不过会呈现在路感模拟中。通过分析齿条力的大小和路感波动，体现在路感方向盘的力矩控制。
同样，还有回正和阻尼控制、高阶路感反馈、补偿控制、冗余仲裁和力矩指令叠加，以及角度控制，因为目前自动驾驶更流行通过目标角度或目标角速度达到目标角度的精确定位、角度控制和转向轮位置协调，实现脱手控制、手动/自动驾驶切换或L3向L2切换等。角度控制可以让驾驶员主动接管或被动接管整车有一个安全过渡。另外，后轮转向控制算法在很大程度上依赖前轮转向实现，后轮转向是一个执行器，这个过程中还涉及前后轮主动协调。
横向控制不单是方向盘转向控制，还有纵向控制，比如过转向、坡道制动、对接路面等，如何保证更好的制动效果，或在转向失效或异常时保证紧急转向的实施，涉及转向和制动的协调控制。
通过进行协调控制，比如在过转向或在坡道制动时，会有一个主动转向过程；在转向失效时，会有一个强制转向或差速转向过程，以保证整体转向制动的协调，最终达到转向效果。
横向稳定控制流程
横向稳定控制流程是从底盘域基础上实现的横纵向稳定性，根据车辆动力学和轮胎动力学，对轮胎附着系数进行修正。
根据线控底盘发展路线图，2025年前，主要是研究轮胎的横向和纵向控制；
2030年后，会进行横纵垂相关的研究。
基于横向纵向主要进行车辆动力学和轮胎动力学相关研究，以得出动态稳定域，通过安全等级限制进行修正，得到相关指令，再进行车辆受控稳定性研究。
整个过程和路面附着系数、车型参数、轮胎模型相关联，所以横向稳定控制要考虑自动驾驶、整车动力学稳定性需求，以及操纵稳定性指标要求、轮胎动力学要求，还要考虑转向制动如何协调，所以单纯看转向，有很大的局限性，但如果从横向角度去看，很多东西可以在前期进行知识储备。
线控转向组件关键参数
主流线控转向组件目前有两类，一是摇臂式，比如商用车；二是齿轮齿条线控转向器。上图是路感协同管柱，取消了中间轴，构成一个完全解耦的线控转向部件。另外，还有方向盘隐藏或收缩机构、路感协同器、转向执行器。2010年之前这种设计比较少见，基本上都是分离的，2010年后，功率组件形式逐步成为主流，因为环境恶劣，控制器的设计指标、稳定性要求越来越高，需要与执行电机集成在一起，容易受到EMC干扰，也容易受电机发热的影响。
一般过了三年期，电机会出现很多问题，前期是控制器出现问题，在大批量生产中有一些体现，需要有控制精度要求、响应时间要求和齿条力估算要求。随速转向基本上采用AUTOSAR架构，用ASIL D等级要求约束，包括最大转速要求和平顺性相关要求。
商用车线控转向
商用车转向原来基本上是循环球占主导，但研究思路逐步拓展，不管是转向和制动，目前电动助力转向最大的改进就是去掉了液压，实现纯电动助力转向。商用车目前还是以液压助力为主。
液压存在维护困难、安装困难、响应困难和控制困难几个难点，如何取消商用车转向中的液压，国内外都在研究，一些企业已将它列入计划，如舍弗勒、采埃孚，都在做这方面的研究。
随速转向比因车速而异，智能电液需要相关的额外补偿系统，比如多刚度稳定系统。因为助力方式不单是电机助力，还有手助力、液压助力、轮胎反弹力等不同来源，所以要把多刚度系统调制成一个稳态系统。如何通过惯量前馈补偿来增强系统的响应性和换向的快捷性也很重要。因为商用车质量过大或惯量过大，或在减速比过大时，会影响路感体验，如何进行主动路感补偿也是商用车转向要考虑的关键问题。
二、线控转向软件架构
线控转向软件架构与底盘安全架构基本上类似，线控转向一方面要实现自身功能，另一方面要满足功能安全fail-operationl需求；第三是在这个平台上有不断迭代可升级的空间，这些都对转向软件架构提出了相关要求。
线控转向系统功能架构
线控转向分为两部分或三部分，一是转向盘总成，其中有两部分：路感模拟和管柱调节，管柱调节可能是隐藏或可调式，对转向盘总成有相关的要求，涉及一些相关部件；而转向执行机构总成涉及主流的滚动丝杠方式，也有四轮独立360度角模块或±90度角模块转向机构。这些系统与自动驾驶安全等级的渗透率需求直接相关，渗透率越低越难落地。国外也发布了路线图，在2024年/2025年会推出整体L3或L4驾驶，所以对线控转向提出了很高要求。
当然，这种系统在L2时也有一些应用场合，技术的足够成熟必须要有很多市场反馈的数据样本来进行验证，其在L2中的优势包括随速减速比，比如低转速时掉头，打很小的角度车轮就可以达到最大角度，可以很快捷轻便地掉头、转向。虽然有一点需求，但其成熟度必须有大量的市场售后数据支撑。
线控转向冗余架构
冗余架构更侧重硬件层面，但软件离不开硬件，所以要在硬件冗余架构配置基础上去做相关开发，而不是完全脱离硬件系统，或脱离底层软件。因为两者毕竟是硬件载体和算法载体，涉及双电源、双传感、双电机、双控制板、多核冗余。
基于功能安全，一般功能核要再加一个锁步核，在单系统中，可以满足ASIL D要
求，但对冗余架构fail-operationl要求来说，就要对功能核进行划分，两个功能核再加一个锁步核进行相关实施，也就是三核。
随着信息安全要求，硬件信息安全也逐步提上日程，当然需要成本比较高的一些工程支持和工具链。多总线校验、力矩仲裁和分配也是双系统要考虑的问题。功能安全要求也必须满足，不能在失效后野蛮地把电机关掉，把域区关掉，把MCU输出关掉，把电源关掉关，而对大于等于L3来说，还要有部分助力或降级助力，甚至是全部助力，ADAS扩展接口要预留。
这套架构不单满足转向执行，也包括路感协同。从安全级别来讲，路感协同不仅是方向盘控制和助力，功能安全还有更高的要求。在实际项目和案例中，功能安全级别、整个软件架构和转向控制是同样的级别要求，甚至某些场景安全级别要比转向控制场景更高。
两路相关系统涉及之间的校验和仲裁，如何进行互相诊断和信息互相校验也是比较重要的内容。
我们申请的一个专利中，在两块硬板之间有一个柔性电路板，通过它实现100兆到200兆通讯速率，在关键算法层面采用单步校验，而不是用接插件。接插件有损耗、干扰，对高频信号有影响。很多高频信号、串行信号都是板级通讯，而不是板和板之间、同板的通讯。在设计过程中，做了很多项目实例，通过两层之间的接插件实现的冗余系统成功率不太高。
线控转向软件安全设计方法
根据AUTOSAR工具链，建立了从ASW到RTE到BSW的平面三层架构。在这个过程中，如何对EGAS的功能安全三层架构进行纵深配置，将整个软件架构构成一个多维度设计方式非常重要。其中有相关设计技巧需要不断讨论，比如一些功能究竟放在哪一个核中，哪一个核作为功能核或监测功能的核，如何实现相互校验。
在不同核中，核与核之间的通讯，核与核之间的校验如何快速响应，也是实际底软配置中要考虑的问题，因为有的单片机满足不了这种设计需求。
线控执行系统功能安全冗余架构
从功能安全层面讲，需要ASIL D等级的双备份系统，而不是一关了之的架构，需要失效时能够运行，比如双路pass的交互，需要满足ASIL D的要求，其中的Master和Slave MCU也要满足ASIL D的要求；域区和芯片也要满足相关要求，执行系统采用六相电机来满足ASIL D的要求。
整体架构理论上可以满足FIT 100要求，即10的9次方小时中所发生的错误次数或个数。根据理论算法，有很多数据支撑，特别是国外的数据，可以达到FIT 100，双电源达到FIT 10。
实际上，功能安全涉及很多内容，有很多依据，比如安全等级的制定、风险概率，国外做的比较完善。美国的很多交通事故数据分析很详细，比如某一次交通事故由什么问题引起，是转向制动，还是方向盘，或者是转向失灵、不可控，都有详细的说明，有足够的样本或数据反馈。在国内这些数据很难取得，所以很多还是依靠国外的数据，特别是危害程度分析国内还比较欠缺。
单纯把国外的样本拿来有一定局限性，功能安全不断往前发展，采集足够的样本后，才能理直气壮说满足了ASIL D，系统是否达到FIT 10和FIT 100。
模式转换与多输入接口
自动驾驶模式下的线控转向涉及驾驶请求、其他方式干预、驾驶员转向干预和模式转换。最重要的是在转换过程中保证安全，如果没有安全保证，风险就很大。特别是在L3向L2或自动向手动转换过程中，如果发生故障，如何处理是需要研究的问题。
指令需求包括直接角度输入、目标力矩输入和直接力矩输入，也包括齿条力估算需求。现在，线控系统中的接口多样化，也要进行研究或预留。
为了满足线控转向的关键技术要求，L3需要基本助力转向，而双系统有管理、仲裁分配等相关需求，在实际过程中需要研究一些关键技术。
路感协同控制器架构，包括方向盘协同控制、齿条力观察器、可变角传动比。在这方面，需要研究如何把软件架构搭建好是整体软件架构要考虑的问题。
三、冗余系统的互诊与仲裁
双系统基本上是基于硬件，中间部分基于软件。冗余系统的互诊和相关仲裁涉及硬件和软件。
冗余系统协作机制
协作机制包括多余度互诊、状态仲裁、同步控制。目前，典型同步控制是为了实现六相电机更低
的噪音、更低的力矩波动和更高的效率。现在行业典型的是三同步：采样同步、调用电机算法时间点同步、PWM输出同步，都需要考核。
没有同步，就不能更好地控制噪声和波动。遵循三同步来实现相关设计，可以实现相关MPS余度互诊，当一个MPS出现问题时，另外一路可以实现诊断。两个MPS有一路丢失了，这时是什么状态，安全级别如何，也是要考虑的问题。
任务交互
在上电检测阶段，车只要不动，转向坏了，对安全级别要求都很低；即使短路，只要不起火，转向乱动，也不会构成人身危害；而车一旦动起来，安全需求就非常强烈，因此要把工作做在前面，在上电测试阶段的模式控制最为关键。
所以不要抱怨，上电检测要300毫秒、550毫秒，这是为了后期更好的安全着想，上电检测的东西多才能保证安全，比如上电检测最起码要做上一次驾驶周期的状态回调，还有当前状态的扭距、角度、域区、传感器，甚至车速信号的实时检测。
线控转向的余度设计
余度设计分为片内和双系统，还有一部分是机械，比如片内单核、多核冗余；双系统中信号互诊、主从仲裁、双电源、双电机、冗余机构、双总线，这样的设计对整体余度设计提出了要求，要满足相关类型和冗余交互的要求。在做设计时，要在整个架构中把上述内容提前设计好。
通讯的冗余交互
因为是fail operational，需要三种通讯的物理通道，一方有问题要能及时识别，还要知道是什么样的问题，然后辨别出自己的问题，还要辨别出是不是该方自己辨别出了自己的问题，第三方也要清楚当前的状态。所以提出了三种冗余交互的物理通道，为了实现安全级别，通讯级别提的更高。
线控系统力矩仲裁与分配
这个过程还涉及仲裁和分配，双路输出不可避免地需要仲裁，分清主从，以谁为主。如果发生一些故障怎么识别，比如CAN总线或车速信号发生问题，但电机驱动正常，就要利用驱动功能；同样道理，如果电机驱动有问题，可能整体上就会关掉。
异构设计在功能安全中，特别是线控转向过程中非常重要。冗余设计有两种方式，同构是投票机制，必须是3、5、7奇数决定哪一个为主，数据是不是准确，所以不可避免造成硬件成本增加。异构机制是仲裁机制，即根据结果程度，或模型预测方式，分析后果如何，做出决定。异构可以降成本，但算法比较复杂，因此在异构设计中，要进行相应的评价，再进行一个安全的执行。
The entire design is complementary in terms of heterogeneous software and hardware. Implementation by software alone is ineffective. Dual sensors are used to implement monitoring, and the severity of consequences is used as an evaluation criterion to achieve safe execution. For many dangerous events that may lead to safety incidents, it is better to make mistakes in judgment than to execute them.
4. Road sense collaboration technology
Road sense collaboration technology involves the control of rack assist, such as the DP-EPS assist controller, and above it is the feel controller. In this process, it is necessary to achieve interaction in some way, to experience the road feel and hand feel through signals, and to feel the fluctuations of the road surface.
Estimate the time of the desired road feel from the driver, vehicle model to vehicle status, use the dynamics model and related compensation to obtain the desired feedback torque, and carry out road sense motor control and road sense motor feedback control through these two levels. Overall control of road feel.
Road sense simulator system technical requirements
In the road sense feedback and angle control closed loop, including the road sense collaborative controller and the power assist controller, the relationship between them is estimated through the displacement angle related to the motor torque and rack force, which not only presents the magnitude of the torque and the rack force The size also reflects the impact of fluctuations in the low, medium and high frequency bands. The rack force estimation is substituted into the control algorithm, and finally the relevant calculation results are obtained - the relationship between the variable steering ratio, achieving road feel and coordinated control.
According to relevant requirements, such as road feel, direction, variable transmission ratio, active return, steady-state power control, inertia compensation, friction compensation, overheating, overload, overpressure, emergency steering, zero adjustment, angle control, end protection, Its functional safety level is higher than that of EPS and RWA, such as road feel feedback.
Other related indicators include: responsiveness, resolution, delay time, feedback cycle, response accuracy, overshoot, and rack force estimation accuracy, which are all requirements of the road sense simulator. The overall development cycle will not be lower than EPS or RWA. .
rack force filter
The rack force filter enters the filter and road sense torque MAP through the rack force estimator, observer, and private CAN, and calculates the friction torque, resistance torque, inertia moment, and active backing torque through the steering wheel angular velocity and vehicle speed to obtain The desired feedback torque is then implemented by the road-sensing motor.
5. Test and evaluation of steering by wire
Regarding the key components of steering-by-wire and their testing and evaluation, there are currently enterprise standards at home and abroad, but they are not too detailed.
Control stability evaluation index
There are mainly two aspects of standards. Although the standards set by each company are different, they come from two sources. One is based on steering-related steering stability index requirements, or comes from autonomous driving, such as lane keeping, APA, etc. Or the requirements for the steering system at the driving assistance system level, so the evaluation indicators are mainly automatic driving command requirements and handling stability.
Main indicators of wire-controlled chassis
From a chassis perspective, power, economy, and passability are the main indicators related to steer-by-wire and brake-by-wire. Of course, the indicators among various OEMs are different, and the level of departure is different. Some autonomous driving requirements Different from the algorithm, the selected execution mechanism is also different, resulting in some differences in these indicators, but they are basically related requirements.
Chassis domain integrated design test conditions
The relevant standards based on the handling stability evaluation index are integrated test conditions. The typical ones that are closely related to steering are steady-state rotation, steering lightness, steering return, angular step and angular pulse, as well as the vehicle's time domain and Frequency domain testing, serpentine testing, and central area testing are all tests that are often performed in dynamics or motion control.
SBW and EPS torque step input signal response test
For a system, relevant research is done around the time domain and frequency domain, both of which have different cases and output requirements. For example, when making a step, it depends on the actual responsiveness and the requirements for vehicle body stability indicators, especially the response of the front wheel angle. For example, if the steering wheel of the road feeling simulator is turned to an angle, the angle of tire response can be discussed.
SBW and traditional EPS include those with and without intermediate shafts, depending on whether the system response index requirements are good or bad. On the one hand, adding an intermediate shaft will create some degrees of freedom in the space gap. Using steering-by-wire road feel simulation will cause algorithm lag. It requires rack force estimation and various filtering to get the results, which are then transmitted through the bus. For tires, you need to actually do some simulation and testing.
System sinusoidal signal response test
From the sinusoidal signal input, we can see the bandwidth and whether the time interval or hysteresis within the bandwidth is reasonably designed. Of course, the designed algorithms are different. For example, the commonly used Kalman filter estimation may affect the time interval. How to shorten the time interval to make the system stable needs to be considered during the actual calibration process and also paid attention to during the simulation process.
Verification and evaluation of double line shifting conditions
Steering is a circular motion, and relevant tests must be done under double-shifting conditions. EPA status, front wheel angle status, front and rear wheel angle status, and four-wheel independent status must all be tested. Only by comparing with the specifications can we get the results. Output the results of the entire system test.
Wire control component test platform
This is the relevant test component and platform developed by our research institute.
Wire control chassis HIL bench test content
The newly built wired chassis platform can realize functional safety-related tests such as wired steering, wired braking, and chassis domain. The entire test scenario is set up based on the safety of intelligent driving functions, and some remote interfaces are also opened. For example, customers in Changchun, Shenzhen or Chongqing can access through the remote client, do relevant tests, and feedback data on the client. Current test objects include tests related to brake steering and chassis domains.
The above five parts are all important and can be discussed in more detail.
京公网安备 11010802033920号