Figure 5.2: Interfaces Provided by Persistency to Other Functional Clusters
8f55c4801def9db78e13b88d8d8e6a84d057da40dc7582338eb2c79970f24ebb
1. Diagrammtyp & Architektur-Kontext
UML-Klassendiagramm und Komponentendiagramm der AUTOSAR Adaptive Platform (Spezifikation AUTOSAR_AP_SWS_Persistency, Release R25-11). Es stellt die statische Spezifikation der Schnittstelle FileStorage dar, die vom Functional Cluster Persistency für daemon-basierte Plattform-Funktionscluster bereitgestellt wird. Das Diagramm repräsentiert die bereinigte und typkorrigierte Schnittstellendefinition für dateibasierten Zugriff in R25-11.
2. Komponenten, Entitäten & Schnittstellen
Zentrale Entität ist «aapAPI,aapPortInterface» FileStorage mit folgenden Operationen:
- DeleteFile()
- FileExists()
- GetAllFileNames()
- GetCurrentFileSize()
- GetFileInfo()
- OpenFileReadOnly(): ReadAccessor
- OpenFileReadWrite(): ReadWriteAccessor
- OpenFileWriteOnly(): WriteAccessor
- RecoverFile()
- ResetFile()
Der bereitstellende Functional Cluster ist «aapFunctionalCluster» Persistency (Realisierungsbeziehung). Drei daemon-basierte funktionale Cluster nutzen die Schnittstelle über gerichtete Abhängigkeiten mit «use» und «aapRequiredPort»:
- «aapFunctionalCluster» Diagnostic Management (Stereotyp verkürzt als «aapFunctionalClust...»),
- «aapFunctionalCluster» Update and Configuration Management,
- «aapFunctionalCluster» Vehicle Update and Configuration Management.
3. Dynamisches Verhalten & Sequenzablauf
Statisches Strukturmodell ohne Zeitachse. Zur Laufzeit steuern UCM, Vehicle UCM und Diagnostic Management die Ablage von Log-, Konfigurations- und Software-Paketdateien. Der Zugriff erfolgt nach Dateiprüfung (FileExists(), GetFileInfo()) über die typisierten Accessor-Methoden. Durch die Einführung des Rückgabetyps WriteAccessor bei OpenFileWriteOnly() wird nun auf Schnittstellenebene sichergestellt, dass bei rein schreibendem Öffnen keine Leseoperationen über den Accessor ausgeführt werden können. Bei Fehlern greifen RecoverFile() und ResetFile() zur Rückführung in konsistente Zustände.
4. Normative Relevanz & Entwickler-Hinweise
Normativ signifikant ist die Korrektur des Rückgabetyps von OpenFileWriteOnly() von ReadWriteAccessor zu WriteAccessor. Dies stellt eine normative API-Änderung dar, die bei Portierung von R24-11 auf R25-11 beachtet werden muss: Aufrufender Code darf über das Write-Only-Handle keine Lesemethoden mehr erwarten oder aufrufen. Die funktionale Portanbindung im Software-Design für Diagnostic Management, UCM und Vehicle Update and Configuration Management bleibt unverändert, erfordert aber die Re-Kompilierung gegen die typkorrigierten ara::per-Header der R25-11.
Zugeordnete Anforderungen
Diese Angaben zeigt der Versions-Explorer.