SNIP_ADAPTIVE_CAN_FIGURE_Figure_3_46_MANIFESTSPECIFICATION

Figure 3.46: Modeling of ComSpec for persistency Note that the specification of encryption as described in [TPS_MANI_01073] does not impose a binding contract. An integrator may reasonably have various reasons to overrule the configuration in the PersistencyDataProvidedComSpec. It would simply not make any sense to statically model the encryption algorithms by means of an enumeration in the AUTOSAR meta-model and consequently require an update of this very enumeration in the AUTOSAR meta-model and XML schema in order to be able to use that hipster encryption algorithm that happens to fulfill ambitious needs in terms of encryption for a specific purpose. [TPS_MANI_01075] Specification of redundancy of persistent data ⌈ The attribute PersistencyDataProvidedComSpec.redundancy can be taken to specify whether the respective key-value database shall store data redundantly from the perspective of the designer of the software-component. ⌋(RS_MANI_00027) In contrast to the definition of encryption the specification of redundancy doesn’t leave much freedom for the designer of a software-component. This person may only state that the values in the corresponding key-value database shall be or shall not be stored redundantly . 155 of 602 — AUTOSAR CONFIDENTIAL — Document ID 713: AUTOSAR_TPS_ManifestSpecification