ISO 26262 is a series of standards regulating electrical and electronic components installed in road vehicles with a focus on their safety. ISO-26262-6 is part of that series focusing on "Product development at the software level" and covers software application design, production and testing.
ISO 26262-6:2018 prescribes ways to identify and mitigate safety risks for automotive applications. These methods depend on so-called Automotive Safety Integrity Levels (ASILs) which represent safety risk severity classes related to a specific software application. There are 4 ASILs marked with letters A through D from least to most severe, where ASIL-D stands for potential death or severe injury.
It is important to understand that GitLab itself cannot be ISO-26262 certified since it does not run within a road vehicle. Instead, GitLab and software development process implemented on top of it can significantly support teams in achieving the actual automotive application compliance. This can be achieved by:
ISO 26262 relies on the V-Model known in the automotive industry as a framework for matching requirements (left bar of a V) with corresponding tests (right bar of a V) on all levels to provide traceability.
V-Model as defined by ISO-26262 standard
It is important to observe there is no time scale in this picture. The standard does not insist all requirements are known prior to development nor does it prescribe waterfall model. On the contrary in section 5.2 it says:
Development approaches or methods from agile software development can also be suitable for the development of safety-related software, but if the safety activities are tailored in this manner, ISO 26262-2:2018 6.4.5 is considered. However, agile approaches and methods cannot be used to omit safety measures or ignore the fundamental documentation, process or safety integrity of product rigour required for the achievement of functional safety.
and further:
Continuous integration based on an automated build system can support consistency of sub-phases and facilitate regression tests. Such a build system typically performs code generation, compiling and linking, static code analysis, documentation generation, testing and packaging. It allows, subject to tool chain and tool configuration, repeatable and, after changes, comparable production of software, documentation and test results.
The standard recommends defining requirements in accordance with ASIL level of a software application under development. These requirements need to be built and maintained in a traceable, versioned way.
You can manage work items needed to build requirements (as well as code) using GitLab issues. GitLab Pages in turn, can be used to store, version and manage requirements. GitLab Pages are building templated static webpages directly out of the repository. Repositories can be used to store any file type, including PDFs, spreadsheets, Word documents, and more. A common choice is to use Markdown files for documentation, which make it easy to modify and track changes to the files directly from GitLab. The result is a:
In fact, the page you are reading just now is generated using the same mechanism.
For documentation which should be versioned but is not subject to rigorous review and approval workflow, wiki is built into each GitLab project. Wiki pages can be created and managed through an easy-to-use web interface. A complete history of all wiki pages is maintained.
Successful digital product lifecycle does not end when the product is shipped. Listening to users feedback and incorporating it into the product is paramount to its success. Using Service Desk, you can interact with and collect feedback from customers and other external stakeholders. This allows you to seamlessly monitor, document, and evaluate feedback as part of your software maintenance process, straight from GitLab.
The standard prescribes specific guidelines for software architecture design, for example:
These recommendations are similar to modern microservice architecture of any enterprise application. Known consequences of applying them include smaller, easy to automate test surface and in consequence faster change cycle. This creates an opportunity for test-driven development, where requirements are expressed as code and executed on each change to ensure consistency, traceability and eliminate human error.
The standard requires several practices for safe coding. Some of them are language-specific, some not:
Some of the violations may be detected automatically, for example by MISRA scanner, some others can be found by peers during code review. Regardless of the method used it is worth testing early and often. GitLab makes it easy to work following GitLab flow with short-lived feature branches and early merges into master. This helps:
GitLab Flow: tests executed on each commit, test information readily available during code review
GitLab can also help by running code quality scan on each commit. If the built-in code scanner is not sufficient or appropriate for your work environment, it is easy to integrate third-party scanner.
An important part of ongoing code quality management, both from governance and psychological standpoint, are code reviews. Every time change gets merged to master it must be seen by the team. GitLab supports that by protecting branches from which releasable code should be built (e.g. disallowing direct push to master). Merge Request contains results of all relevant tests executed automatically on the branch as well as a link to live environment where the application version under review is installed. Detailed merge request approval rules can be used to require review by specific persons or teams. This process can further be enhanced with push rules ensuring every commit meets certain documentation standards, e.g. every commit must be linkable with a specific work item or requirement.
For those tests which are not automated, you can use description templates and task lists to define test suites, link them back to requirements and provide an easy-to-use way to track those tasks for developers and reviewers.
With more cars being connected to the Internet and updated over the air, application security starts playing a significant role in automotive software development. ISO-26262-6:2018 encourages securing your application in section 5.2
Cybersecurity can also be considered when developing the embedded software of a particular item, see ISO 26262-2:2018, 5.4.2.3. In order to be able to develop software, specific topics are addressed in this clause concerning the modelling, design and/or programming languages to be used, and the application of guidelines and tools.
Similarly to code quality, security can only be done well in an iterative process. Treating it as an afterthought leads to significant rework best case and project failures in the worst one. GitLab can execute a complete set of security scans at each change cycle:
All scan results are available for the team approving Merge Request.
Not all tests can be done by scanning code. More complex scenarios, especially around autonomous driving or fault injection, can only be executed by exposing the live application to some input and measuring their output. The traditional factor limiting development team throughput is the availability of the suitable test environments. A modern solution to this conundrum is using Kubernetes to provision complete test environments and data. This approach brings a couple of advantages:
GitLab has adopted Kubernetes early and provides first-class support for deploying both your test workflows as well as application this way. Kubernetes clusters can be added company, department and project level giving you flexible balance between speed and cost efficiency.
Traditional toolchain used for digital product development is built of many domain tools integrated together. In some cases, these systems require third party plugins for integration or automotive-specific use-cases. These integrations are by definition fragile and they result in a brittle process. With data scattered across systems, often kept in many copies it tends to be notoriously difficult to audit too. The underlying toolchain is risky and expensive to operate eating resources which could be spent on product development.
GitLab is different. Being single application for entire software development lifecycle GitLab helps you:
THE INFORMATION PROVIDED ON THIS WEBSITE IS TO BE USED FOR INFORMATIONAL PURPOSES ONLY. THE INFORMATION SHOULD NOT BE RELIED UPON OR CONSTRUED AS LEGAL OR COMPLIANCE ADVICE OR OPINIONS. THE INFORMATION IS NOT COMPREHENSIVE AND WILL NOT GUARANTEE COMPLIANCE WITH ANY REGULATION OR INDUSTRY STANDARD. YOU MUST NOT RELY ON THE INFORMATION FOUND ON THIS WEBSITE AS AN ALTERNATIVE TO SEEKING PROFESSIONAL ADVICE FROM YOUR ATTORNEY AND/OR COMPLIANCE PROFESSIONAL.