Refine Your Search

Topic

Search Results

Technical Paper

Towards Establishing Continuous-X Pipeline Using Modular Software-in-the-Loop Test Environments

2021-09-22
2021-26-0412
Software-in-the-Loop (SiL) test environments are the ideal virtual platforms for enabling continuous-development, -integration, -testing -delivery or -deployment commonly referred as Continuous-X (CX) of the complex functionalities in the current automotive industry. This trend especially is contributed by several factors such as the industry wide standardization of the model exchange formats, interfaces as well as architecture definitions. The approach of frontloading software testing with SiL test environments is predominantly advocated as well as already adopted by various Automotive OEMs, thereby the demand for innovating applicable methods is increasing. However, prominent usage of the existing monolithic architecture for interaction of various elements in the SiL environment, without regarding the separation between functional and non-functional test scope, is reducing the usability and thus limiting significantly the cost saving potential of CX with SiL.
Magazine

Automotive Engineering: September 2021

2021-09-01
Editorial EV bafflers, surprises and ironies Altair honors weight-saving innovations Finding failure inside lithium-metal batteries GM puts its new 2023 Corvette V8 on a different 'plane' SAE Standards News New ISO-SAE 21434 for cybersecurity Supplier Eye Preparing for the new, faster product cadence 2022 Jeep Compass gets class-leading safety upgrades Toyota muscles-up 4-cylinder for revised 2022 GR 86 coupe Q&A Manufacturing consultant Laurie Harbour lays out the looming pressures on the auto-manufacturing supply base.
Standard

Taxonomy and Definitions for Terms Related to Cooperative Driving Automation for On-Road Motor Vehicles

2021-07-16
CURRENT
J3216_202107
This document describes machine-to-machine (M2M) communication to enable cooperation between two or more participating entities or communication devices possessed or controlled by those entities. The cooperation supports or enables performance of the dynamic driving task (DDT) for a subject vehicle with driving automation feature(s) engaged. Other participants may include other vehicles with driving automation feature(s) engaged, shared road users (e.g., drivers of manually operated vehicles or pedestrians or cyclists carrying personal devices), or road operators (e.g., those who maintain or operate traffic signals or workzones). Cooperative driving automation (CDA) aims to improve the safety and flow of traffic and/or facilitate road operations by supporting the movement of multiple vehicles in proximity to one another. This is accomplished, for example, by sharing information that can be used to influence (directly or indirectly) DDT performance by one or more nearby road users.
Technical Paper

xEV Propulsion System Control-Overview and Current Trends

2021-04-06
2021-01-0781
Propulsion system control algorithms covering the functional needs of xEV propulsion (‘x’ donates P0-P4 configurations) systems are presented in this paper. The scope and foundation are based on generic well-established HEV controller architectures. However, unlike conventional HEV (series, parallel and power split) powertrains, the next generation of integrated electric propulsion configurations will utilize a single micro controller that supports multiple control functions ranging from the electric machines, inverters, actuators, clutch solenoids, coolant pumps, etc. This presents a unique challenge to architect control algorithms within the AUTOSAR framework while satisfying the complex timing requirements of motor/generator-inverter (MGi) control and increased interface definitions between software components to realize functional integration between the higher level propulsion system and its sub-systems.
Standard

Potential Failure Mode and Effects Analysis (FMEA) Including Design FMEA, Supplemental FMEA-MSR, and Process FMEA

2021-01-13
CURRENT
J1739_202101
This FMEA standard describes potential failure mode and effects analysis in design (DFMEA), supplemental FMEA-MSR, and potential failure mode and effects analysis in manufacturing and assembly processes (PFMEA). It assists users in the identification and mitigation of risk by providing appropriate terms, requirements, rating charts, and worksheets. As a standard, this document contains requirements—”must”—and recommendations—”should”—to guide the user through the FMEA process. The FMEA process and documentation must comply with this standard as well as any corporate policy concerning this standard. Documented rationale and agreement with the customer are necessary for deviations in order to justify new work or changed methods during customer or third-party audit reviews.
Research Report

Unsettled Issues Regarding Policy Aspects of Automated Driving Systems

2020-08-31
EPR2020016
Automated driving systems (ADS) represent an area of considerable investment and activity within the transportation sphere. The potential impact of ADS on safety, efficiency, and user experience are extremely significant. To get the most from the technology, it is important to ensure that policies are developed to support the balance between achieving public sector objectives and supporting private sector innovation. This SAE EDGE™ Research Report explores the policy aspects related to ADS technology, explains the key stakeholders, identifies unsettled issues, and proposes a number of steps to move forward and improve the current situation. It is hoped that the report will provide a valuable resource to those involved in the definition of ADS policy from both public and private perspectives. It is also intended to serve as a resource for those involved in ADS planning and development and public sector staff involved in other aspects beyond ADS policy.
Standard

Taxonomy and Definitions for Terms Related to Cooperative Driving Automation for On-Road Motor Vehicles

2020-05-07
HISTORICAL
J3216_202005
This document describes machine-to-machine (M2M) communication to enable cooperation between two or more participating entities or communication devices possessed or controlled by those entities. The cooperation supports or enables performance of the dynamic driving task (DDT) for a subject vehicle with driving automation feature(s) engaged. Other participants may include other vehicles with driving automation feature(s) engaged, shared road users (e.g., drivers of manually operated vehicles or pedestrians or cyclists carrying personal devices), or road operators (e.g., those who maintain or operate traffic signals or workzones). Cooperative driving automation (CDA) aims to improve the safety and flow of traffic and/or facilitate road operations by supporting the movement of multiple vehicles in proximity to one another. This is accomplished, for example, by sharing information that can be used to influence (directly or indirectly) DDT performance by one or more nearby road users.
Best Practice

AVSC Best Practice for Describing an Operational Design Domain: Conceptual Framework and Lexicon

2020-04-15
CURRENT
AVSC00002202004
An ADS-operated vehicle’s operational design domain (ODD) is defined by the manufacturer based on numerous factors. Research is underway at other organizations to define and organize ODD elements into taxonomies and other relational constructs. In order to enhance collaboration and communication between manufacturers and developers and transportation authorities, common terms and consistent frameworks are needed. The conceptual framework presented by Automated Vehicle Safety Consortium establishes a lexicon that can be used consistently by ADS developers and manufacturers responsible for defining their ADS ODD. A common framework and lexicon will reduce confusion, align expectations, and therefore build public trust, acceptance, and confidence.
Technical Paper

Test Method for the SAE J3138 Automotive Cyber Security Standard

2020-04-14
2020-01-0142
This paper will provide an Overview of Automotive Cyber Security Standards related to the Vehicle OBD-II Data Link. The OBD-II Connector Attack Tree is described with respect to the SAE J3138 requirements for Intrusive vs. non-Intrusive Services. A proposed test method for SAE J3138 is described including hardware and software scripting. Finally, example test results are reviewed and compared with a potential threat boundary.
Best Practice

Guidelines for Mobility Data Sharing Governance and Contracting

2020-04-08
CURRENT
MDC00001202004
Digitally enabled mobility vehicles and services, including dockless bikesharing and electric scooter sharing, are generating and collecting a growing amount of mobility data. Mobility data holds great potential to support transportation officials and their efforts to manage the public right-of-way, but the unlimited distribution of mobility data carries untested risks to privacy and public trust. The Mobility Data Collaborative™ has identified the need to improve and coordinate understanding among all parties around foundational policy and legal issues to support mobility data sharing, including privacy and contracting. The guidelines are geared towards supporting a scalable mobility data sharing framework that aligns the interests of the public and private sectors while addressing privacy, transparency, data ownership, and consumer trust.
Standard

Hardware Protected Security for Ground Vehicles

2020-02-10
CURRENT
J3101_202002
Access mechanisms to system data and/or control is a primary use case of the hardware protected security environment (hardware protected security environment) during different uses and stages of the system. The hardware protected security environment acts as a gatekeeper for these use cases and not necessarily as the executor of the function. This section is a generalization of such use cases in an attempt to extract common requirements for the hardware protected security environment that enable it to be a gatekeeper. Examples are: Creating a new key fob Re-flashing ECU firmware Reading/exporting PII out of the ECU Using a subscription-based feature Performing some service on an ECU Transferring ownership of the vehicle Some of these examples are discussed later in this section and some have detailed sections of their own. This list is by no means comprehensive.
Journal Article

Cyberattacks and Countermeasures for Intelligent and Connected Vehicles

2019-10-14
Abstract ICVs are expected to make the transportation safer, cleaner, and more comfortable in the near future. However, the trend of connectivity has greatly increased the attack surfaces of vehicles, which makes in-vehicle networks more vulnerable to cyberattacks which then causes serious security and safety issues. In this article, we therefore systematically analyzed cyberattacks and corresponding countermeasures for in-vehicle networks of intelligent and connected vehicles (ICVs). Firstly, we analyzed the security risk of ICVs and proposed an in-vehicle network model from a hierarchical point of view. Then, we discussed possible cyberattacks at each layer of proposed network model.
Journal Article

Data Privacy in the Emerging Connected Mobility Services: Architecture, Use Cases, Privacy Risks, and Countermeasures

2019-10-14
Abstract The rapid development of connected and automated vehicle technologies together with cloud-based mobility services is transforming the transportation industry. As a result, huge amounts of consumer data are being collected and utilized to provide personalized mobility services. Using big data poses serious challenges to data privacy. To that end, the risks of privacy leakage are amplified by data aggregations from multiple sources and exchanging data with third-party service providers, in face of the recent advances in data analytics. This article provides a review of the connected vehicle landscape from case studies, system characteristics, and dataflows. It also identifies potential challenges and countermeasures.
Magazine

Autonomous Vehicle Engineering: September 2019

2019-09-05
Editorial The new 'face' of privacy The Navigator No trust in AI systems without data protection Innovation Nation In the mobility space, Israel is rivaling Silicon Valley for smarts and start-ups - and beats it in chutzpah. Autonomy in your Face Biometric technology is deemed essential to ensuring AV driving safety and advancing the user experience-if privacy issues don't derail its deployment. About Face! To win acceptance, deployment of facial-recognition technology needs to fit within a picture-perfect consumer and legal framework that balances benefits with privacy protection. The Vehicle as Gaming Device Audi spin-off Holoride uses VR to turn the back seat into an entertainment platform. BlackBerry Tech Duo Sees Emergence of Vehicle-based Platforms Though likely to provide the OS of autonomy, BlackBerry also anticipates a larger shift to automobiles as software platforms.
Standard

E/E Data Link Security

2019-07-12
CURRENT
J2186_201907
This SAE Recommended Practice establishes a uniform practice for protecting vehicle components from "unauthorized" access through a vehicle data link connector (DLC). The document defines a security system for motor vehicle and tool manufacturers. It will provide flexibility to tailor systems to the security needs of the vehicle manufacturer. The vehicle modules addressed are those that are capable of having solid state memory contents accessed or altered through the data link connector. Improper memory content alteration could potentially damage the electronics or other vehicle modules; risk the vehicle compliance to government legislated requirements; or risk the vehicle manufacturer's security interests. This document does not imply that other security measures are not required nor possible.
Article

Software needs security, and security needs software: a scientific overview

2019-04-22
Software needs security. That's a consequence of using software to control critical systems. It's difficult because software is inherently a complex artifact, even when the code just consists of a single sequential program in a single programming language, with well-defined inputs and outputs. Of course, actual software rarely if ever has such a simple structure. Security needs software. That's a consequence of the complexity just mentioned. No process can ensure security at scale unless it is automated by using software itself: programming languages, verification tools, software platforms.
Technical Paper

Analyze This! Sound Static Analysis for Integration Verification of Large-Scale Automotive Software

2019-04-02
2019-01-1246
Safety-critical embedded software has to satisfy stringent quality requirements. One such requirement, imposed by all contemporary safety standards, is that no critical run-time errors must occur. Runtime errors can be caused by undefined or unspecified behavior of the programming language; examples are buffer overflows or data races. They may cause erroneous or erratic behavior, induce system failures, and constitute security vulnerabilities. A sound static analyzer reports all such defects in the code, or proves their absence. Sound static program analysis is a verification technique recommended by ISO/FDIS 26262 for software unit verification and for the verification of software integration. In this article we propose an analysis methodology that has been implemented with the static analyzer Astrée. It supports quick turn-around times and gives highly precise whole-program results.
Technical Paper

Trust-Based Control and Scheduling for UGV Platoon under Cyber Attacks

2019-04-02
2019-01-1077
Unmanned ground vehicles (UGVs) may encounter difficulties accommodating environmental uncertainties and system degradations during harsh conditions. However, human experience and onboard intelligence can may help mitigate such cases. Unfortunately, human operators have cognition limits when directly supervising multiple UGVs. Ideally, an automated decision aid can be designed that empowers the human operator to supervise the UGVs. In this paper, we consider a connected UGV platoon under cyber attacks that may disrupt safety and degrade performance. An observer-based resilient control strategy is designed to mitigate the effects of vehicle-to-vehicle (V2V) cyber attacks. In addition, each UGV generates both internal and external evaluations based on the platoons performance metrics. A cloud-based trust-based information management system collects these evaluations to detect abnormal UGV platoon behaviors.
Technical Paper

Vehicle E/E Architecture and Its Adaptation to New Technical Trends

2019-04-02
2019-01-0862
With the ever-increasing requirements on vehicle performance, as well as the trend of vehicle becoming an integral part of a much bigger ecosystem involving automated driving, intelligent transportation and smart city, more and more electrical/electronic (E/E) systems are integrated in vehicles. Vehicle E/E architecture being the fundamental organization of E/E components, the relationship among the components and with the environment, as well as the principles guiding the design and evolution, has essential influences on vehicle E/E system functions and performance. This paper gives the definition of vehicle E/E architecture and provides different views. The guidelines, contents and process of E/E architecture design are discussed. The evolution of E/E architecture, influence of the latest technical trends including electrification, automated driving, and connectivity functions on E/E architecture, and how vehicle E/E architecture adapts to the technical trends are studied.
X