An Industrial Experience Report about Challenges from Continuous Monitoring, Improvement, and Deployment for Autonomous Driving Features

Abstract

Using continuous development, deployment, and monitoring (CDDM) to understand and improve applications in a customer's context is widely used for non-safety applications such as smartphone apps or web applications to enable rapid and innovative feature improvements. Having demonstrated its potential in such domains, it may have the potential to also improve the software development for automotive functions as some OEMs described on a high level in their financial company communiqués. However, the application of a CDDM strategy also faces challenges from a process adherence and documentation perspective as required by safety-related products such as autonomous driving systems (ADS) and guided by industry standards such as ISO-26262 [1] and ISO21448 [2]. There are publications on CDDM in safety-relevant contexts that focus on safety-critical functions on a rather generic level and thus, not specifically ADS or automotive, or that are concentrating only on software and hence, missing out the particular context of an automotive OEM: Well-established legacy processes and the need of their adaptations, and aspects originating from the role of being a system integrator for software/software, hardware/hardware, and hardware/software. In this paper, particular challenges from the automotive domain to better adopt CDDM are identified and discussed to shed light on research gaps to enhance CDDM, especially for the software development of safe ADS. The challenges are identified from today's industrial well-established ways of working by conducting interviews with domain experts and complemented by a literature study.

On STPA for Distributed Development of Safe Autonomous Driving: An Interview Study

“…The participants had on average 15 years of automotive experience and 12 years of safety experience, making them well-suited to provide valuable insights on the topic being studied. The study design was carefully planned and executed to ensure that the data collected was reliable and valid 1 .…”

“…Discussion: To satisfy the need for traceability between safety analysis methods and requirements, ISO 26262 [4] proposes a structure for safety requirements in four levels of abstraction in its "Management of safety requirements" section (Part 8, clause 6). It also illustrates the traceability between these levels, which has been expanded to cover ISO 21448 by Nouri et al [1]. A hierarchy of requirements, starting from safety goals to functional safety requirements, technical safety requirements and hardware and software safety requirements, requires at least three levels of safety analysis to create traceability to the parent requirement.…”

“…Autonomous Drive (AD) is foreseen as a possible solution towards vision zero [1]. However, arguing for the safety of such a system is hard due to the complexity of such a softwareintensive system, and because of the use of novel technologies like machine learning.…”