In the railway industry, in particular amongst system and component suppliers, offering custom-designed products is an increasingly growing challenge. The number of customer-specific variants increases, particularly in systems with a high complexity and high portion of software. This challenge can be successfully met with a platform approach. In the following, it is explained how such an approach can be successful and, especially, what this means in terms of validation, assessment and homologation.
The Platform Approach and Its Advantages
A “platform” is a set of software building blocks, processes, and tools from which products or product variants are derived. Regarding the software architecture, the modularity and granularity of the building blocks must be considered with regards to freedom from interference and effect chains. This results in advantages in terms of flexibility, time and costs every step of the way, in other words for both customers and suppliers. These customer benefits can be scaled up to the operator. However, to leverage the advantages, important platform aspects must be considered when defining the cooperation and working model, project structure and customer-supplier interface. Furthermore, the platform approach must be followed on both the system level and the software level from the beginning, starting with concept and requirements phases.
Experience shows that complex products often cannot be specified sufficiently on the client side from the beginning. In combination with a conventional project structure that is mostly based on the waterfall model, time-consuming and costly adjustment loops ensue. In a platform-based approach, this fuzziness can be limited most of the time to a few components or effect chains. Therefore, platforms support agile collaboration models, which have proven to be effective in circumstances where conditions and requirements remarkably change in the course of a development project.
The Two-Stage Approach
To implement a platform approach in the railway area compliantly to the CENELEC standards, a two-stage development process is required: the “generic” stage refers to the development of the platform and the “specific” stage refers to building the final product from the platform.
Regarding the development of software for railway applications, the overall software architecture and interfaces are defined in the generic stage and the components or building blocks are developed. Here, the software architecture is at the centre of a software platform from which specific software is generated for complex, multi-variant systems. This software architecture must consider all possible software components and their interfaces. When defining the interfaces, it is important to ensure that the components act as independent items to reduce the possibility of common-cause failures and guarantee freedom from interference. In the generic stage, software assurance processes are conducted on the component level, leading to “validated” components that are released with their application conditions.
In the specific stage, the building blocks from the platform are selected and configured while observing the relevant application conditions from the generic stage. Then the final software is generated. The integration and overall software testing are performed at this stage while also considering application conditions from the platform. This ensures that the correct software components have been selected and their interfaces are consistent with one another. An application condition from the platform can be, for example, that only certain combinations of components are allowed.
A high degree of transparency and communication between customer and supplier is crucial here. This must already be considered in the acquisition phase and be reflected in the project structure.
For an efficient development process that masters complexity, the separation between the generic and the specific part must be considered across all development stages, from requirements engineering to validation. The generic part of the software consists of different software components, which can also be available in different versions. Each software component must adhere to the interface specified in the software architecture. The requirements document of the generic part of the software describes the functionality of individual modular software components. Ideally, the granularity of the requirements documents corresponds to that of the software components. The functionality of each software component must be described in its own software specification and thus implemented and tested in a corresponding granular manner. Consequently, each component can be developed independently. The aim is to provide validated software components of the platform at the end of the generic development.
Ideally, the steps from the platform to the specific software through to the selection of the required components are highly automated. Each specific software requires a dedicated specification sheet, which contains the information on the selection of the components as well as their configuration and provides the basis for the development of the final software.
Validation, Assessment, and Homologation
On the validation side, the use of a platform approach, with the advantages of mastering complexity and a high number of variants, also means pursuing a two-stage strategy. In the “generic” stage, the validation evaluates the software components as defined in the software architecture specification. The generic software architecture as well as each software component and their variants are therefore considered separate and validated independently. The validation statements for the individual software components remain valid as long as the components are not changed and the application conditions are followed. In the case of improvements and adjustments, the modularity of the individual software components, combined with a tool-supported impact analysis, mostly allows for a very local consideration of the relevant differences or “deltas” during the validation. Here, the validation activities can also be meaningfully and easily processed within an agile collaboration model.
The specific software is generated by considering the software architecture, selecting the necessary components, and configuring the final software. Thus, for validation it must be examined whether the defined process for generating the specific software has been adhered to and whether the relevant application conditions have been observed. Furthermore, the integration test results as well as the overall test results must be examined for a full validation. Finally, the validation statements from the generic parts are checked and referenced. Because the validation of the specific software mostly uses the validation of the generic parts, specific product variants can be efficiently generated and validated.
Re-validation in particular can be performed in an efficient manner this way. The same holds true for re-assessment and re-homologation, where only the deltas must be considered for the generic parts and the integration and overall assurance as well as validation activities must be considered for the specific parts.
This overview shows that with software platforms, complex and multi-variant software systems can be developed iteratively and incrementally, while also being validated, assessed, and homologated efficiently. Success factors are: to set up and establish the platform approach consistently across all phases of the product life cycle, to anchor the two-stage approach along the software development process, and to achieve a high degree of automation and thus efficiency as well, by selecting the appropriate tools and methods.
