With the rapid advancement of automated driving technology, numerous manufacturers deploy vehicles with auto-driving features. This highlights the importance of ensuring the quality of automated driving software. To achieve this, characterizing bugs in automated driving software is important, as it can facilitate bug detection and bug fixes, thereby ensuring software quality. Automated driving software typically has a modular architecture, where software is divided into multiple modules, each designed for its own functionality for automated driving. This may lead to varying bug characteristics. Additionally, our recent study has shown a correlation between bugs caused by code clones and the functionalities of modules in automated driving software. Hence, we consider the modular structure when analyzing bug characteristics. In this article, we analyze 3,078 bugs from two representative open-source Level-4 automated driving systems, Apollo and Autoware. By analyzing the bug report description, title, and developers’ discussions, we have identified 20 bug symptoms and 17 bug-fixing strategies and analyzed their relationships with the respective modules. Our analysis achieves 12 main findings offering a comprehensive view of bug characteristics in automated driving software. We believe our findings can help developers better understand and manage bugs in automated driving software, thereby improving software quality and reliability.

AI programming has become a popular topic in recent years. Code suggestion, with code suggestion being a key capability of AI programming. Copilot, an “AI programmer” that provides code suggestions from natural language descriptions, has been launched by GitHub and OpenAI. By far, Copilot has been widely used by millions of developers. However, little work has systematically evaluated the correctness of Copilot’s suggestions. We conducted an empirical study on all 2,033 LeetCode problems to assess Copilot’s code generation across four mainstream languages: C, Java, JavaScript, and Python. We have found that: (1) 70.0% of problems received at least one correct suggestion, with language-specific rates of 29.7% (C), 57.7% (Java), 54.1% (JavaScript), and 41.0% (Python); (2) correctness decreases as problem difficulty increases, with acceptance rates of 89.3% (easy), 72.1% (medium), and 43.4% (hard); (3) acceptance rates vary across problem domains from 49.5% to 90.1%, while Graph problems challenge C and Python most, and Prefix Sum and Heap challenge Java and JavaScript most; (4) for the incorrect suggestions, we further summarize 17 types of error reasons accounting for their incorrectness and analyzed possible causes for why these errors occur. We believe our study can provide valuable insights into Copilot’s capabilities and limitations.

During software evolution, commits with various purposes, such as bug fixes, feature additions, improvements, etc., are continuously applied to software systems. This could drift software architecture from its planned design, and even cause architectural decay, that negatively affects software maintenance. Although prior studies have presented that even daily code commits could induce architectural changes, and the commit-level analysis has been widely used for multiple software comprehension and maintenance tasks, there is little work analyzing the architectural changes at the commit level. To bridge this gap, we conduct a study investigating the relationships between commits and architectural changes. Through our evaluation of thirty projects, we have shown that the architecture remains stable after most of the commits. However, there still exists a large portion of commits (27% of all studied commits) that have induced architectural changes, which deserve more attention. This further suggests the importance of analyzing architectural changes at the commit level. Meanwhile, we present a suite of commit-level metrics strongly correlated with architectural changes. Finally, we propose prediction models that can effectively forecast how much of the architecture would be changed after a commit.

With the continuous improvement of artificial intelligence technology, autonomous driving technology has been greatly developed. Hence automated driving software has drawn more and more attention from both researchers and practitioners. Code clone is a commonly used to speed up the development cycle in software development, but many studies have shown that code clones may affect software maintainability. Currently, there is little research investigating code clones in automated driving software. To bridge this gap, we conduct a comprehensive experience study on the code clones in automated driving software. Through the analysis of Apollo and Autoware, we have presented that code clones are prevalent in automated driving software. about 30% of code lines are involved in code clones and more than 50% of files contain code clones. Moreover, a notable portion of these code clones has caused bugs and co-modifications. Due to the high complexity of autonomous driving, the automated driving software is often designed to be modular, with each module responsible for a single task. When considering each module individually, we have found that Perception, Planning, Canbus, and Sensing modules are more likely to encounter code clones, and more likely to have bug-prone and co-modified clones. Finally, we have shown that there exist cross-module clones to propagate bugs and co-modifications in different modules, which undermine the software's modularity.