[ad_1]
//php echo do_shortcode(‘[responsivevoice_button voice=”US English Male” buttontext=”Listen to Post”]’) ?>
Artificial-intelligence software, particularly deep-learning (DL) components, is currently the most advanced and economically feasible solution for achieving autonomous systems, such as autonomous cars. However, the nature of DL algorithms and their current implementation are at odds with the stringent software development process followed in safety-critical systems like cars, satellites and trains.
Traditional safety-relevant software follows a top-down approach, decomposing components and propagating safety requirements accordingly until reaching sufficiently simple software units. Those software units on their own, and their composition, are based on explicit and data-independent control algorithms—for example, algorithms process the data—but algorithms are designed and verified without needing any data.
The traditional design process for software clashes with the way DL software is generally built. DL software architecture (type, number and organization of the layers) is built empirically, following an intuition-based optimization process, and with (training) data in the loop to tune DL model parameters.
Hence, the DL software obtained consists of large atomic software units, has a generic goal (e.g., performing predictions as accurately as possible), is created out of specific training datasets that implicitly determine DL software functionality and goes through a challenging decomposition into smaller components (i.e., layers of a neural network). Those components on their own have little or no meaning, lack specific requirements against which they can be assessed and have internal characteristics that cannot be modified independently, as training for DL software occurs atomically and with strong coupling across all components (layers) of the DL software.
Moreover, increasingly accurate DL software is generally obtained from more complex implementations in which the number of components (layers), their size (number of neurons) and the amount of data used for training increase, hence widening the gap between the traditional development process of safety-critical software and that of DL software.
SAFEXPLAIN, a project funded by the European Union, aims to bridge this gap to enable the certification of DL-based software components, including those that inherit high-integrity fail-operational safety requirements. SAFEXPLAIN considers three pillars simultaneously:
- DL-based software components
- Certification practice against functional safety standards
- Efficient execution on commercial platforms
Considering any of those pillars on its own is doomed to fail. For instance, safety standards impose the development of software building on explicitly defined deterministic algorithms built without data in the loop. However, DL software often has a stochastic nature. Implicit learning of the intended algorithm with provided training examples can produce predictions with varying confidence, including erroneous predictions. Hence, attempting to restrict DL software characteristics to current safety standards is a hopeless task.
Instead, SAFEXPLAIN works toward tailoring the design of DL software in a way that properties needed to meet general safety principles, such as explainability and traceability, emerge naturally. In this way, even if DL-based software components are atomic in nature, they already provide properties on which arguments for certification can be elaborated.
Simultaneously, SAFEXPLAIN works toward adapting safety standards to enable unconventional ways to certify software; for instance, inheriting practice for hardware components in which failure rates are part of the development process, while preserving key principles that allow elaborating safety arguments, so that DL software characteristics needed to achieve meaningful prediction accuracy can be potentially admitted in the development process of safety-critical systems.
Both pillars—DL software development and certification against safety standards—need to occur within the bounds set by the third pillar: efficient execution on commercial platforms. In other words, performance achieved and computing resources required must be within bounds.
Hence, SAFEXPLAIN envisions DL software development that is constrained without altering its main steps to preserve accuracy and platform-related requirements so that alternative safety arguments can ultimately be elaborated, enabling the certification of DL-based software solutions. To that end, SAFEXPLAIN will consider a wide range of safety patterns with different requirements considering variations in the integrity levels (e.g., from low to high integrity) as well as fail-safe and fail-operational functionalities. All of these elements will vary software architecture and, hence, the safety requirements inherited by DL-based software components.
SAFEXPLAIN will deliver practical solutions tailoring DL software solutions used in industrial applications, considering current safety-related certification practice in industry, and existing high-performance platforms relevant for safety-related applications. This will be done continuously assessing project solutions against industrial case studies from the automotive, space and railway domains as representatives of safety-critical applications.
[ad_2]
