We describe a modular framework suitable for continuous update in synch for all aspects: functionality, realization and analysis, respectively. This enables continuous deployment at a high pace of complex automotive products as for example, ADS. We also describe the interplay between run time and design time, which constitutes the driving force in a successful DevOps. We assume a unified architectural approach with modular modelling to serve the needs of safe DevOps from the different aspects: A key enabler for the fast updateability expected from CD is to decouple the modules as much as possible without losing control of relevant relationships. Thus, we propose a contractual framework guaranteeing this decoupling. This means that as long as all contracts are respected for a module, it can be updated independently of others. Note that this implies that requirements are neither to be seen as derived top-down nor aggregated bottom up, but as design decisions for each module balancing not only cost and benefit, but also updateability. A safety case can be automatically generated in the continuous integration process, given that all modules bring a valid and complete safety case fragment. The core safety argument claims (rationale claims and satisfaction claims) for the fragments, follow the fulfilment of the contracts. These are supported by process claims and environment culture claims. Each fragment also brings its own evidence. Different strategies for generating evidence depend on the coordinates in the multi-dimensional contract space. For the lower levels of abstraction, this typically means to support satisfaction claims with very large amount of data from representative operations. For this purpose each such module shall have a forward-looking evolvement plan, where monitors are designed in one design-time phase based on a later hypothetical future assurance case. Putting these monitors in the product, they collect in run-time (Ops phase) data that can serve as evidence when aggregated and analysed in upcoming design time (Devs phase), which generates the assurance case for even later operations (Ops Phase). An extensive explanation including an example is given in the full paper, where is shown modules in all dimensions with corresponding contracts. Further elaboration to existing related work is also given in the full paper. Furthermore, the example shows a sequence of development and operation phases, and how the interplay is done, especially for those modules where the Ops data is key for creating evidence in the assurance cases.
Beckman et al. (Tue,) studied this question.
Synapse has enriched 5 closely related papers on similar clinical questions. Consider them for comparative context: