Abstract
As multiple functions have been added to single-core-based engine electronic control units (ECUs) in vehicles, automotive researchers and manufacturers have actively studied multi-core architecture for engine ECUs. Multi-core architecture can provide load balancing and parallelism that can meet the requirements of international organization standard (ISO) 26262. However, since real-world engine ECUs have the most complex automotive open system architecture (AUTOSAR)-based control logic and datasets among automotive ECUs, developing multi-core-based engine ECUs is a substantial amount of work. Thus, automotive researchers and manufacturers will need new methodologies for multi-core-based engine ECUs. In this paper, we focus on designing a multi-core migration methodology and applying it to a real-world AUTOSAR-based engine ECU from HYUNDAI. We verify its practicability and enhanced performance. In conclusion, through connection with other automotive domain ECUs, it is demonstrated that a multi-core engine ECU using our migration technology can be applied in real-world automotive vehicles, leading to a significant improvement in performance.
Highlights
Recently, the amount of data that must be processed by an engine electronic control unit (ECU) and the number of automotive functions embedded in an engine electronic control units (ECUs) have increased due to addition of new ECUs and advancements in vehicles
MULTI-CORE MIGRATION TECHNOLOGY we suggest a shared data protection scheme, load balancing, and a method of optimizing migration to an actual multi-core-based engine ECU
Our migration technology includes core load balancing, shared data inconsistency, and optimization using memory and offset allocation. We apply it to the HYUNDAI engine ECU
Summary
The amount of data that must be processed by an engine electronic control unit (ECU) and the number of automotive functions embedded in an engine ECU have increased due to addition of new ECUs and advancements in vehicles. To calculate the critical section execution time of each allocation case, LBM needs to know the number of shared data items To calculate this number, it is necessary to compare the data names of tasks in different cores and analyze the data read/write direction. Τnormal was calculated in the second step; we only need to know the task j critical section execution time of each case p(τcprjitical ), which is the sum of the shared data copy time (vpcjTcopy), update time (vpujTupdate) and spinlock time (Tlock ).
Sign-in/Register to view highlights & summary Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callDisclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
