Diagnostic Communication Manager (DCM)

Die synchrone und nicht-reentrante Funktion Dcm_Init dient der grundlegenden Initialisierung des DCM-Moduls [SWS_Dcm_00037]. Sie nimmt über den Parameter ConfigPtr einen Zeiger auf das Konfigurationsset bei Post-Build-Varianten entgegen und besitzt keinen Rückgabewert [SWS_Dcm_00037]. Während der Ausführung initialisiert das Modul alle globalen DCM-Variablen mit den Werten aus der Konfiguration [SWS_Dcm_00334].

Im Rahmen des Initialisierungsablaufs werden verschiedene Funktionsbereiche und Zustände konfiguriert:

• DDDID-Verwaltung: Ist der Konfigurationsparameter DcmDDDIDStorage auf FALSE gesetzt, initialisiert das DCM beim Hochlauf alle dynamisch definierten Datenbezeichner (DDDIDs) als nicht vorhanden [SWS_Dcm_00866]. Ist der Parameter auf TRUE gesetzt, werden die DDDID-Definitionen aus dem NvM wiederhergestellt [SWS_Dcm_00867].
• Response on Event (ROE): Das DCM überführt den Zustand jedes Ereignisses während Dcm_Init in den Status 'ROE cleared' [SWS_Dcm_00872].
• Authentifizierungsstatus: Wenn DcmDspAuthenticationPersistStateModeRuleRef nicht konfiguriert ist oder die referenzierte Modus-Regel zu false ausgewertet wird, versetzt das Modul alle Authentifizierungszustände in den Zustand 'deauthenticated' [SWS_Dcm_01480].
• Kommunikationsstatus: Nach Abschluss von Dcm_Init setzt das DCM den Parameter ActiveDiagnostic auf 'DCM_COMM_ACTIVE' [SWS_Dcm_01069].

Hinsichtlich der Ausführungsumgebung ist festgelegt, dass Dcm_Init nicht reentrant ist [SWS_Dcm_00037]. Spezifische Fehlercodes sowie standardisierte Fehlermeldungen an DET oder DEM sind für diesen Initialisierungsdienst in der Schnittstellenspezifikation nicht ausgewiesen [SWS_Dcm_00037].

Verwendung

Die synchrone Schnittstelle Dcm_DemTriggerOnDTCStatus (Service-ID 0x2B) ist über den Header Dcm_Dem.h verfügbar und dient dazu, Änderungen des UDS-Statusbytes an das DCM zu melden [SWS_Dcm_00614]. Dies gestattet dem DCM das Auslösen von Response-on-Event-Ereignissen (ROE) für den Diagnosedienst-Subservice OnDTCStatusChanged [SWS_Dcm_00614]. Beim Aufruf nimmt die Funktion drei Eingabeparameter entgegen: den betroffenen Fehlercode DTC (uint32), den vorherigen Zustand DTCStatusOld (Dem_UdsStatusByteType) sowie den aktualisierten Zustand DTCStatusNew (Dem_UdsStatusByteType) [SWS_Dcm_00614]. Ein- und Ausgabeparameter existieren nicht [SWS_Dcm_00614].

Rückgabewerte und Fehlerbehandlung

Als Rückgabewert liefert die Funktion den Typ Std_ReturnType, wobei laut Spezifikation ausnahmslos E_OK zurückgegeben wird [SWS_Dcm_00614]. Spezifische Fehlercodes, Rückfallwerte oder gesonderte Benachrichtigungen an DEM oder DET sind für diesen Aufruf nicht ausgewiesen.

Nebenläufigkeit und Zusammenspiel

Die Funktion ist als reentrant eingestuft und verfügt über eine synchrone Ausführungssemantik [SWS_Dcm_00614]. Hinsichtlich des Zusammenspiels mit Diagnoseanforderungen gilt eine feste Randbedingung: Falls im DCM aktuell eine Anforderung zum Löschen des Ereignisspeichers (EventMemory) verarbeitet wird, muss das DCM eingehende Aufrufe des Callbacks Dcm_DemTriggerOnDTCStatus ignorieren [SWS_Dcm_01410].

Die Funktion Dcm_BndMWriteBlockFinish dient als Benachrichtigungsschnittstelle des BndM an das DCM, um den Abschluss einer Block-Schreiboperation anzuzeigen [SWS_Dcm_91088]. Die Funktion ist in der Header-Datei Dcm.h deklariert, besitzt die Service-ID 0x7a, liefert keinen Rückgabewert (void) und wird synchron ausgeführt [SWS_Dcm_91088].

Die Schnittstelle erwartet zwei Übergabeparameter [SWS_Dcm_91088]:

• BlockId (Typ: BndM_BlockIdType): Kennzeichnet den Block, dessen Schreibvorgang abgeschlossen wurde.
• result (Typ: BndM_ResultType): Übermittelt das Ergebnis der Schreiboperation an das DCM.

Das funktionale Zusammenspiel und das Verhalten im Fehlerfall sind an zuvor durch das DCM ausgelöste atomare BndM-Schreiboperationen gekoppelt:

• Wird Dcm_BndMWriteBlockFinish mit dem Status result = E_OK aufgerufen, sendet das DCM eine positive Diagnoseantwort auf die ausstehende Anforderung [SWS_Dcm_01584].
• Wird die Funktion mit result = E_NOT_OK aufgerufen, reagiert das DCM im Fehlerfall mit einer negativen Diagnoseantwort 0x72 (generalProgrammingFailure) [SWS_Dcm_01585].

Bezüglich der Nebenläufigkeit ist Dcm_BndMWriteBlockFinish als nicht reentrant (Non Reentrant) spezifiziert [SWS_Dcm_91088]. Aufrufer müssen folglich sicherstellen, dass die Funktion nicht parallel oder unterbrechend durch mehrere Kontexte aufgerufen wird.

Verwendung und Aufrufkontext

Die Funktion Dcm_SetDeauthenticatedRole wird synchron und reentrant ausgeführt ([SWS_Dcm_91069]). Sie ermöglicht es einer Softwarekomponente, für eine durch connectionId identifizierte Verbindung eine neue Rolle deauthenticatedRole vom Typ Dcm_AuthenticationRoleType für den deauthentifizierten Zustand zuzuweisen ([SWS_Dcm_91069], [SWS_Dcm_01486]). Als Rückgabewert wird ausnahmslos E_OK geliefert ([SWS_Dcm_91069]).

Zustandsbedingungen und Fehlerbehandlung

Ein Aufruf wird vom DCM ausschließlich verarbeitet, wenn sich die Verbindung im deauthentifizierten Zustand (deauthenticated state) befindet ([SWS_Dcm_01487]). Da die Signatur keine alternativen Fehlerwerte vorsieht und stets E_OK zurückgibt ([SWS_Dcm_91069]), dürfte ein Aufruf außerhalb dieses Zustands vermutlich ohne Fehlermeldung verworfen werden. Frage Q-6f14770eae6ce896 (offen) Spezifische DET- oder DEM-Ereignisse sind in der Spezifikation nicht definiert.

Gültigkeitsdauer und Lebenszyklus

Wird die Rolle für den deauthentifizierten Zustand erfolgreich übernommen ([SWS_Dcm_01486]), bleibt diese Zuweisung temporär bestehen:

• Die gesetzte Rolle wird verworfen, sobald die Verbindung in den authentifizierten Zustand (authenticated state) wechselt ([SWS_Dcm_01488]).
• Die Gültigkeit endet spätestens bei einem Reset des Steuergeräts ([SWS_Dcm_91069]).

Die synchrone und reentrante Funktion Dcm_GetSecurityLevel fragt die aktuell aktive Sicherheitsstufe des DCM ab und stellt diese bereit [SWS_Dcm_00338]. Die Funktion ist über den Header Dcm.h deklariert und übergibt den ermittelten Statuswert über den Ausgabeparameter SecLevel vom Typ Dcm_SecLevelType* an den Aufrufer. Als Rückgabewert wird laut Spezifikation ausnahmslos E_OK zurückgeliefert [SWS_Dcm_00338].

Die Ermittlung der internen Sicherheitsstufe basiert auf dem vom Tester im Rahmen des Dienstes SecurityAccess übermittelten Parameter SecurityAccessType gemäß der festen Umrechnungsformel SecurityLevel = (SecurityAccessType + 1) / 2 [SWS_Dcm_00338].

Im Zusammenspiel mit der übergeordneten Diagnosedienstverarbeitung greift unter anderem das DSP-Submodul auf diesen Wert zurück: Empfängt das Modul eine konfigurierte Anfrage mit dem Subfunktionstyp „requestSeed“ (ungerader Wert) und ist die zugehörige Zugriffsebene laut Dcm_GetSecurityLevel bereits aktiv, setzt das DSP-Submodul den Seed-Inhalt auf 0x00 [SWS_Dcm_00323].

Hinsichtlich Nebenläufigkeit und Fehlerbehandlung ist die Funktion als reentrant definiert [SWS_Dcm_00338]. Da keine spezifischen Fehlercodes oder DET-Prüfungen spezifiziert sind und stets E_OK zurückgegeben wird, dürfte keine Nullzeigerprüfung stattfinden; Aufrufer müssen daher vermutlich stets einen gültigen Zeiger auf Speicherplatz für SecLevel übergeben. Frage Q-5402d82ac0151b22 (offen)

Die synchrone Funktion Dcm_ResetToDefaultSession ermöglicht es der Applikation, die aktive Diagnosesitzung in die Standard-Sitzung (Default Session) zurückzusetzen [SWS_Dcm_00520]. Ein typischer Anwendungsfall ist die automatische Beendigung einer erweiterten Diagnosesitzung, sobald ein Fahrzeug eine vorgegebene Geschwindigkeitsschwelle überschreitet [SWS_Dcm_00520].

Verwendung und Fehlerbehandlung

• Schnittstelle und Parameter: Die Funktion ist über Dcm.h mit der Service-ID 0x2a verfügbar, besitzt die Signatur Std_ReturnType Dcm_ResetToDefaultSession (void) und erfordert keine Übergabeparameter [SWS_Dcm_00520].
• Rückgabewert und Fehler: Als Rückgabetyp wird Std_ReturnType zurückgeliefert, wobei ausnahmslos der Wert E_OK zurückgegeben wird [SWS_Dcm_00520]. Spezifische Fehlercodes, DET-Laufzeitprüfungen oder DEM-Ereignisse sind in den Anforderungen für diesen Aufruf nicht spezifiziert.

Nebenläufigkeit und Zusammenspiel

Die Ausführung erfolgt synchron und ist als reentrant deklariert [SWS_Dcm_00520].

Neben dem eigentlichen Sitzungswechsel stößt Dcm_ResetToDefaultSession zwingend einen Moduswechsel für den ModeDeclarationGroupPrototype DcmDiagnosticSessionControl an [SWS_Dcm_01062]. Hierbei ruft die Funktion intern SchM_Switch_<bsnp>_DcmDiagnosticSessionControl(RTE_MODE_DcmDiagnosticSessionControl_DCM_DEFAULT_SESSION) auf, um die Systemumgebung über den Wechsel in die Standard-Sitzung zu benachrichtigen [SWS_Dcm_01062].

Die synchrone Funktion Dcm_TriggerOnEvent (Service-ID 0x2D), bereitgestellt über den Header Dcm.h, dient dem Auslösen eines Ereignisses, das mit einer ResponseOnEvent-Anforderung (ROE) verknüpft ist [SWS_Dcm_00521].

Aufruf und Funktionsweise

Der Aufrufer übergibt als einzigen Parameter RoeEventId (Eingabeparameter vom Typ uint8), welcher das auszulösende Ereignis identifiziert; Ein- oder Ausgabeparameter existieren nicht [SWS_Dcm_00521]. Sobald die Funktion aufgerufen wird, prüft das DCM den Zustand des Ereignisses: Ist das übergebene RoeEvent aktiv, löst das DCM das entsprechende Ereignis aus [SWS_Dcm_00920]. Das DCM führt den mit dem Ereignis assoziierten Dienst aus, sofern der zugehörige Modus der RoeEventId auf ‚ROE started‘ steht [SWS_Dcm_00521].

Rückgabewerte und Validierung

Der Aufruf liefert synchron einen Status vom Typ Std_ReturnType zurück, der über die Gültigkeit des Parameters Auskunft gibt [SWS_Dcm_00521]:

• E_OK: Der übergebene Wert für RoeEventId ist gültig [SWS_Dcm_00521].
• E_NOT_OK: Der Wert von RoeEventId ist ungültig [SWS_Dcm_00521].

Nebenläufigkeit und Eigenschaften

Die Schnittstelle ist als reentrant spezifiziert [SWS_Dcm_00521]. Sie kann somit nebenläufig aufgerufen werden, um Ereignisse synchron an das DCM zu melden [SWS_Dcm_00521].

Die synchrone und reentrante Funktion Dcm_StartOfReception ([SWS_Dcm_00094]) wird von einem Transportprotokollmodul zu Beginn des Empfangs einer N-SDU aufgerufen – sowohl bei Einzelnachrichten (Single Frame, SF) als auch bei segmentierten Nachrichten (First Frame, FF). Sie kann im Interrupt-Kontext aufgerufen werden ([SWS_Dcm_00094]). Der Aufruf bewirkt unter anderem das Stoppen des S3Server-Timers bei Beginn des Empfangs ([SWS_Dcm_00141]).

Über info werden Nutzdaten und Metadaten übergeben; bei generischen Verbindungen werden hierüber unter anderem SOURCE_ADDRESS_16 gespeichert ([SWS_Dcm_00848]) sowie TARGET_ADDRESS_16 geprüft ([SWS_Dcm_01347]). Ist weder Payload noch Metadatum vorhanden, wird NULL_PTR übergeben ([SWS_Dcm_00094]). Über bufferSizePtr meldet die Funktion den verfügbaren Puffer zur Berechnung der Block Size (BS) zurück ([SWS_Dcm_00094]). Bei erfolgreicher Annahme liefert sie BUFREQ_OK, woraufhin Folgedaten über Dcm_CopyRxData kopiert werden ([SWS_Dcm_00443]).

Fehler- und Ablehnungsfälle werden über den Rückgabewert signalisiert:

• BUFREQ_E_OVFL: Wird zurückgegeben, wenn die angeforderte Länge TpSduLength größer als der im DCM verfügbare Puffer ist ([SWS_Dcm_00094], [SWS_Dcm_00444]). bufferSizePtr bleibt unverändert ([SWS_Dcm_00094]).
• BUFREQ_E_NOT_OK: Wird zurückgegeben, wenn TpSduLength gleich 0 ist ([SWS_Dcm_00642]) oder eine laufende Anforderung auf derselben Verbindung blockiert ([SWS_Dcm_00557]). Bei einer anderen Verbindung entscheidet der Parameter DcmDslDiagRespOnSecondDeclinedRequest, ob mit BUFREQ_E_NOT_OK abgewiesen ([SWS_Dcm_00790]) oder mit BUFREQ_OK akzeptiert wird ([SWS_Dcm_00788]). Nebenläufige TesterPresent-Anfragen werden ebenfalls mit BUFREQ_OK quittiert ([SWS_Dcm_00557]).

Verwendung

Die synchrone Funktion Dcm_CopyRxData wird aufgerufen, um empfangene Daten eines I-PDU-Segments (N-PDU) an die obere Schicht im DCM zu übergeben [SWS_Dcm_00556]. Jeder Aufruf stellt den nächsten Teil der I-PDU-Daten bereit [SWS_Dcm_00556]. Über den Parameter id wird die empfangene I-PDU identifiziert [SWS_Dcm_00556]. Der Zeiger info stellt über SduDataPtr den Quellpuffer sowie über SduLength die Anzahl der zu kopierenden Bytes bereit [SWS_Dcm_00556]. Nach Abschluss des Kopiervorgangs wird die verbleibende freie Puffergröße im DCM über bufferSizePtr zurückgemeldet [SWS_Dcm_00556], [SWS_Dcm_00443].

Wird Dcm_CopyRxData mit einer SduLength von 0 aufgerufen, dient dies der reinen Pufferabfrage [SWS_Dcm_00556]. In diesem Fall darf SduDataPtr ein NULL_PTR sein; die Funktion gibt BUFREQ_OK zurück und trägt die verbleibende Größe des Empfangspuffers in bufferSizePtr ein [SWS_Dcm_00556], [SWS_Dcm_00996].

Zusammenspiel

Vor dem Kopieren muss Dcm_StartOfReception mit BUFREQ_OK abgeschlossen worden sein; nachfolgende Aufrufe von Dcm_CopyRxData kopieren die Daten aus dem bereitgestellten Puffer in den DCM-Puffer und aktualisieren bufferSizePtr [SWS_Dcm_00443].

Fehlerbehandlung

Die Funktion gibt den Status als BufReq_ReturnType zurück: BUFREQ_OK bestätigt das erfolgreiche Kopieren oder die Pufferabfrage, während BUFREQ_E_NOT_OK anzeigt, dass aufgrund eines Fehlers keine Daten kopiert wurden [SWS_Dcm_00556], [SWS_Dcm_00996].

Nebenläufigkeit und Einschränkungen

Dcm_CopyRxData ist reentrant spezifiziert und darf im Interrupt-Kontext aufgerufen werden [SWS_Dcm_00556]. Die Schnittstelle wird über Dcm.h bereitgestellt [SWS_Dcm_00556].

Verwendung und Aufrufkontext

Die synchrone Funktion Dcm_TpRxIndication wird nach dem Empfang einer I-PDU über die TP-API aufgerufen, typischerweise durch das Modul PduR [SWS_Dcm_00093], [SWS_Dcm_00112]. Sie übergibt die PDU-Identifikation (id) sowie das Empfangsergebnis (result) und liefert keinen Rückgabewert zurück [SWS_Dcm_00093]. Da die Funktion reentrant ist und im Interrupt-Kontext aufgerufen werden darf, müssen Aufrufer und Modulzustände für entsprechende Nebenläufigkeit ausgelegt sein [SWS_Dcm_00093].

Verhalten bei fehlerhaftem Empfang

Wird Dcm_TpRxIndication mit einem Ergebniswert aufgerufen, der von E_OK abweicht, darf das Modul Dcm den der referenzierten I-PDU zugewiesenen Puffer nicht auswerten [SWS_Dcm_00344].

Zusammenspiel der Submodule

Das Submodul DSL leitet empfangene Daten ausschließlich dann an das Submodul DSD weiter, wenn der Aufruf mit dem Parameterwert result = E_OK erfolgt ist [SWS_Dcm_00111]. Für Diagnoseanfragen gelten dabei spezifische Regeln:

• Handelt es sich bei der erfolgreich empfangenen Anfrage (Result = E_OK) um den Befehl TesterPresent mit gesetztem suppressPosRspMsgIndicationBit (SID 0x3E, Subfunktion 0x80), setzt das DSL-Submodul den Session-Timeout-Timer S3Server zurück [SWS_Dcm_00112].
• In diesem Fall wird die Anfrage durch das DSL-Submodul nicht zur weiteren Interpretation an das DSD-Submodul weitergeleitet [SWS_Dcm_00113].

Verwendung und Semantik

Die synchrone und reentrante Funktion Dcm_CopyTxData wird von Modulen der unteren Schicht (wie Transportprotokollen) aufgerufen, um Daten eines I-PDU-Segments (N-PDU) für die Übertragung abzurufen [SWS_Dcm_00092]. Über den Parameter info übergibt der Aufrufer den Zielpuffer SduDataPtr und die gewünschte Bytelänge SduLength. Ein Wert von 0 für SduLength kann genutzt werden, um Statusänderungen über retry zu signalisieren oder die Menge verfügbarer Daten abzufragen; SduDataPtr darf in diesem Fall ein NULL_PTR sein [SWS_Dcm_00092]. Über availableDataPtr meldet das DCM die verbleibende Bytezahl im Sendepuffer, die von TP-Modulen zur Bestimmung nachfolgender Segmentgrößen verwendet werden kann und die Zahl der noch zu sendenden Bytes nicht überschreiten darf [SWS_Dcm_00092], [SWS_Dcm_00350].

Pufferverwaltung und Übertragungswiederholung

Über den Parameter retry wird die Quittierung oder Wiederholung von Daten gesteuert [SWS_Dcm_00092]:

• Ist retry ein NULL_PTR, dürfen die Daten direkt nach dem Kopiervorgang aus dem Puffer entfernt werden [SWS_Dcm_00092].
• Bei TP_CONFPENDING müssen zuvor kopierte Daten für eine eventuelle Fehlerbehebung im TP-Puffer verbleiben [SWS_Dcm_00092].
• TP_DATACONF bestätigt alle vor diesem Aufruf kopierten Daten zur Freigabe [SWS_Dcm_00092].
• TP_DATARETRY kopiert Daten ab dem Offset TxTpDataCnt relativ zur aktuellen Position erneut [SWS_Dcm_00092].

Rückgabewerte und Fehlerbehandlung

Wurden die Daten erfolgreich und vollständig kopiert, gibt die Funktion BUFREQ_OK zurück [SWS_Dcm_00092], [SWS_Dcm_00346]. Sind nicht genügend Sendedaten verfügbar, wird kein Kopiervorgang durchgeführt und BUFREQ_E_BUSY zurückgegeben; die untere Schicht kann den Aufruf später wiederholen [SWS_Dcm_00092]. Schlägt die Anfrage fehl, liefert die Funktion BUFREQ_E_NOT_OK [SWS_Dcm_00092]. In diesem Fall ist die Sendeanforderung aus PduR_DcmTransmit() noch nicht abgeschlossen; erst ein abschließender Aufruf von Dcm_TpTxConfirmation beendet den Vorgang und ermöglicht neue Übertragungen [SWS_Dcm_00350].

Nebenläufigkeit

Die Funktion ist reentrant und darf auch im Interrupt-Kontext aufgerufen werden [SWS_Dcm_00092].

Die Callback-Funktion Dcm_TpTxConfirmation ([SWS_Dcm_00351]) wird von der unteren Transportschicht synchron aufgerufen, nachdem eine diagnostische I-PDU auf dem Netzwerk übertragen wurde. Über den Parameter id wird die betroffene I-PDU identifiziert, während result den Erfolg oder Misserfolg des Sendevorgangs meldet ([SWS_Dcm_00351]). Die Funktion besitzt keinen Rückgabewert, ist reentrant und darf explizit im Interrupt-Kontext ausgeführt werden ([SWS_Dcm_00351]).

Beim Aufruf von Dcm_TpTxConfirmation führt das DCM-Modul zentrale Bereinigungs- und Statusübergänge durch:

• Der zugeordnete Sendepuffer wird entsperrt ([SWS_Dcm_00352]).
• Laufende Fehlerüberwachungen wie Page-Buffer-Timeouts sowie P2ServerMax- und P2*ServerMax-Timeouts werden gestoppt ([SWS_Dcm_00353]).
• Die seit dem Empfang (Dcm_TpRxIndication) blockierte DcmPduId der Verbindung wird freigegeben, sodass nachfolgende Anforderungen empfangen werden können ([SWS_Dcm_00241]).
• Das aktuelle Protokoll wird durch die Bestätigung der DSL-Antwort nicht beendet (kein Aufruf von xxx_StopProtocol) ([SWS_Dcm_00624]).

Im Fehlerfall (wenn result einen Fehler anzeigt oder ein Abbruch nach einem fehlgeschlagenen Dcm_CopyTxData bestätigt wird) verlangt [SWS_Dcm_00350] zwingend diesen abschließenden Aufruf, um den Sendeauftrag formell abzuschließen und neue Übertragungen via PduR_DcmTransmit() zu ermöglichen. Bei einer fehlerhaften Bestätigung darf das DSD-Submodul die Diagnoseantwort nicht erneut senden ([SWS_Dcm_00118]).

Zusätzlich markiert die Bestätigung einer Antwort (ungleich NRC 0x78) den regulären Abschluss eines Diagnose-Requests ([SWS_Dcm_01378]). Nach der Bestätigung einer positiven Antwort auf einen EcuReset ignoriert das DCM während der Reset-Verarbeitung alle weiteren Anfragen ([SWS_Dcm_00834]).

Verwendung

Die synchrone Schnittstelle Dcm_TxConfirmation (Service-ID 0x40, deklariert in Dcm.h) wird gemäß [SWS_Dcm_01092] durch das unterlagerte Kommunikationsschnittstellenmodul aufgerufen, um das Senden einer PDU zu bestätigen oder das Fehlschlagen der Übertragung zu melden. Die Funktion besitzt keinen Rückgabewert und verarbeitet zwei Eingangsparameter:

• TxPduId: Bezeichner (PduIdType) der gesendeten PDU.
• result: Status der Übertragung (Std_ReturnType). Gültige Werte sind E_OK bei erfolgreicher Übertragung sowie E_NOT_OK, falls die Übertragung der PDU gescheitert ist.

Fehlerbehandlung und Statusrückmeldung

Das Ergebnis der Übertragung wird dem DCM direkt über den Parameter result signalisiert ([SWS_Dcm_01092]). Spezifische DET- oder DEM-Fehlermeldungen sind im bereitgestellten Spezifikationsauszug für diese Funktion nicht definiert.

Nebenläufigkeit und Aufrufkontext

Hinsichtlich der Reentranz ist Dcm_TxConfirmation reentrant für Aufrufe mit unterschiedlichen PDU-IDs, jedoch nicht reentrant für dieselbe TxPduId ([SWS_Dcm_01092]). Zu beachten ist, dass der Aufruf durch das unterlagerte Modul im Interrupt-Kontext erfolgen kann ([SWS_Dcm_01092]).

Zusammenspiel

Im Fall einer periodischen Übertragung (PeriodicTransmission) wird das DCM gemäß [SWS_Dcm_01073] über Dcm_TxConfirmation aufgerufen, um das jeweilige Sendeergebnis mitgeteilt zu bekommen.

Die synchrone und reentrante Funktion Dcm_ComM_NoComModeEntered (Service-ID 0x21) informiert das DCM-Modul über den Wechsel eines Kommunikationsnetzwerks in den Zustand COMM_NO_COMMUNICATION [SWS_Dcm_00356]. Die Schnittstelle wird über den Header Dcm_ComM.h bereitgestellt, besitzt keinen Rückgabewert und identifiziert das betroffene Netzwerk über den Eingangsparameter NetworkId vom Typ uint8 [SWS_Dcm_00356].

Mit dem Aufruf schaltet das DCM jegliche Kommunikation auf dem angegebenen Netzwerk ab, sodass sowohl der Empfang als auch das Senden von Nachrichten vollständig deaktiviert werden [SWS_Dcm_00148]. Dies schließt folgende Übertragungsarten verbindlich ein:

• Unterbindung von ResponseOnEvent-Übertragungen [SWS_Dcm_00149],
• Deaktivierung periodischer Übertragungen über ReadDataByPeriodicIdentifier (periodicId) [SWS_Dcm_00150] sowie
• Abschaltung normaler Übertragungen [SWS_Dcm_00151].

Infolgedessen darf das DCM-Modul nach Ausführung von Dcm_ComM_NoComModeEntered für diesen Kontext nicht mehr die PduR-Funktion PduR_DcmTransmit() aufrufen [SWS_Dcm_00152].

Wird die Funktion mit einer NetworkId aufgerufen, die keinem im DCM über den Konfigurationsparameter DcmDslProtocolComMChannelRef referenzierten ComM-Kanal entspricht, führt das DCM-Modul keinerlei Aktionen durch und kehrt unverzüglich zurück [SWS_Dcm_01324].

Die synchrone und reentrante Funktion Dcm_ComM_SilentComModeEntered ([SWS_Dcm_00358]) dient dazu, das DCM-Modul über den Wechsel eines Kommunikationsnetzwerks in den Zustand COMM_SILENT_COMMUNICATION zu informieren. Die Schnittstelle besitzt die Service-ID 0x22, liefert keinen Rückgabewert und erwartet als Eingangsparameter NetworkId den Bezeichner des betroffenen Netzwerks ([SWS_Dcm_00358]). Sie wird über die Header-Datei Dcm_ComM.h zur Verfügung gestellt ([SWS_Dcm_00358]).

Sobald dieser Aufruf erfolgt, muss das DCM sämtliche Sendeaktivitäten auf dem betroffenen Netzwerkkanal vollständig einstellen ([SWS_Dcm_00153]). Dies beinhaltet im Detail folgende Maßnahmen:

• die Deaktivierung aller normalen Übertragungen ([SWS_Dcm_00156]),
• das Unterbinden von Response-on-Event-Übertragungen ([SWS_Dcm_00154]) sowie
• das Deaktivieren periodischer Aussendungen im Rahmen von ReadDataByPeriodicIdentifier ([SWS_Dcm_00155]).

Hinsichtlich der Fehlerbehandlung und Randbedingungen ist festgelegt, dass das DCM ohne jede weitere Aktion zurückkehren muss, falls die übergebene NetworkId einem ComM-Kanal entspricht, der im DCM nicht über den Konfigurationsparameter DcmDslProtocolComMChannelRef referenziert wird ([SWS_Dcm_01325]). Spezifische Entwicklungsfehler oder Fehlerrückgabewerte sind für diesen Aufruf nicht spezifiziert.

Interpretation: Der Aufruf dürfte typischerweise durch das Modul ComM erfolgen, sobald der Übergang in den stillen Kommunikationsmodus vollzogen wird. Frage Q-fc9b6303ae0c0e41 (offen)

Die synchrone und reentrante Funktion Dcm_ComM_FullComModeEntered wird über die Header-Datei Dcm_ComM.h bereitgestellt und informiert das DCM-Modul über den Wechsel eines Kommunikationsnetzwerks in den Zustand COMM_FULL_COMMUNICATION [SWS_Dcm_00360]. Als Eingabeparameter dient NetworkId, welche das vom Moduswechsel betroffene Netzwerk identifiziert [SWS_Dcm_00360].

Durch den Aufruf wird jegliche Kommunikation für dieses Netzwerk aktiviert, sodass sowohl der Nachrichtenempfang als auch das Senden freigegeben sind [SWS_Dcm_00157]. Dies schließt folgende Übertragungsarten ein:

• normale Übertragungen [SWS_Dcm_00161],
• Response-on-Event-Übertragungen [SWS_Dcm_00159] sowie
• periodische Übertragungen mittels ReadDataByPeriodicIdentifier [SWS_Dcm_00160].

Sobald Dcm_ComM_FullComModeEntered aufgerufen wurde, verarbeitet das DCM die internen Funktionen DslInternal_ResponseOnOneDataByPeriodicId() und DslInternal_ResponseOnOneEvent() ohne Einschränkungen [SWS_Dcm_00162]. Im zeitlichen Ablauf muss das DCM diesen Aufruf abwarten, bevor die Übertragung einer Diagnoseantwort eingeleitet wird; die Wartezeit darf ab dem Zeitpunkt des Anfrageeingangs nicht länger als P2ServerMax sein [SWS_Dcm_01142].

Im Fehlerfall, wenn die übergebene NetworkId einen ComM-Kanal betrifft, der im DCM nicht konfiguriert ist (Parameter DcmDslProtocolComMChannelRef), kehrt die Funktion unmittelbar und ohne weitere Aktionen zurück [SWS_Dcm_01326].

Verwendung und Semantik

Die synchrone und reentrante Callback-Funktion Dcm_CsmAsyncJobFinished wird vom Crypto Service Manager (CSM) aufgerufen, sobald eine asynchrone Auftragsverarbeitung abgeschlossen ist [SWS_Dcm_91076]. Als Eingabeparameter nimmt sie über result vom Typ Csm_ResultType das Ergebnis des beendeten CSM-Jobs entgegen [SWS_Dcm_91076]. Als Rückgabewert liefert die Funktion stets E_OK zurück [SWS_Dcm_91076].

Konfiguration und Randbedingungen

Integratoren müssen den Namen dieser Funktion in der ECUC-Konfiguration des CSM als Callback für asynchrone Jobs konfigurieren [SWS_Dcm_91076]. Für das DCM steht ausschließlich ein einziger solcher Callback zur Verfügung; die Identifikation des beendeten Auftrags erfolgt laut Spezifikation durch Auswertung des Job-Parameters [SWS_Dcm_91076]. Da die C-Funktionssignatur jedoch lediglich result übergibt, dürfte das DCM den zugehörigen Auftrag intern über den Transaktionszustand der laufenden Authentifizierung ermitteln. Frage Q-04ad1d5fb514f467 (offen)

Die Schnittstelle steht nur zur Verfügung, wenn in der Konfiguration der Parameter DcmDspAuthenticationConnection gesetzt ist (ungleich null) [SWS_Dcm_91076]. Spezifische Fehlerbehandlungen oder DET-Meldungen sind für diesen Aufruf nicht spezifiziert, da der Rückgabewert unveränderlich E_OK ist [SWS_Dcm_91076].

Die synchrone und reentrante Callback-Funktion Dcm_KeyMAsyncCertificateVerifyFinished wird vom Modul KeyM nach Abschluss einer asynchronen Zertifikatsverifizierung aufgerufen [SWS_Dcm_91077]. Sie informiert das DCM über den Abschluss sowie das Resultat des Prüfvorgangs und liefert als Rückgabewert stets E_OK [SWS_Dcm_91077].

Parameter und Funktionsweise

• CertID: Kennung des Zertifikats, dessen Verifizierung abgeschlossen wurde. Anhand dieses Identifikators ermittelt das DCM, welcher Prüfauftrag beendet wurde [SWS_Dcm_91077].
• Result: Rückgabewert und Status des asynchronen Verifizierungsauftrags aus dem KeyM [SWS_Dcm_91077].

Konfiguration und Randbedingungen

Integratoren müssen diesen Funktionsnamen in der ECUC-Konfiguration des KeyM als Callback für asynchrone Jobs konfigurieren [SWS_Dcm_91077]. Da für diese Benachrichtigung nur ein einziger Callback bereitsteht, ist das DCM darauf angewiesen, das jeweilige Zertifikat über den Parameter CertID aufzulösen [SWS_Dcm_91077].

Die Schnittstelle steht ausschließlich zur Verfügung, wenn der Konfigurationsparameter DcmDspAuthenticationConnection im Pfad Dcm/DcmDsp/DcmDspAuthentication konfiguriert ist (!= null) [SWS_Dcm_91077]. Besondere Fehlercodes oder DET-Meldungen sind für diesen Aufruf nicht spezifiziert [SWS_Dcm_91077].

Die Callout-Funktion Dcm_ReadMemory ([SWS_Dcm_00539]), deklariert in Dcm_Externals.h, dient dem DCM zum Auslesen von Server-Speicherdaten anhand von Startadresse (MemoryAddress) und Bytegröße (MemorySize). Die Funktion wird für die UDS-Dienste ReadMemoryByAddress (0x23) ([SWS_Dcm_00495]), ReadDataByIdentifier (0x22) für dynamische DIDs im Adressbereich 0xF200 bis 0xF3FF ([SWS_Dcm_00653]), RequestUpload sowie TransferData benötigt ([SWS_Dcm_00539]). Wird der Parameter MemoryIdentifier nicht verwendet, muss er auf 0 gesetzt werden ([SWS_Dcm_00539]).

Die Schnittstelle ist asynchron und nicht reentrant ([SWS_Dcm_00539]). Der Aufrufstatus wird über OpStatus mit den Werten DCM_INITIAL, DCM_PENDING, DCM_CANCEL oder DCM_FORCE_RCRRP_OK übergeben. Solange der Lesevorgang andauert, gibt die Funktion DCM_READ_PENDING zurück ([SWS_Dcm_00985]). Liefert der Aufruf DCM_READ_FORCE_RCRRP zurück, stößt das DCM unverzüglich das Senden einer RCR-RP-Nachricht (NRC 0x78) an und pausiert weitere Aufrufe bis zur Sendebestätigung ([SWS_Dcm_00839]). Nach Bestätigung der RCR-RP ruft das DCM die Funktion aus Dcm_MainFunction erneut mit OpStatus = DCM_FORCE_RCRRP_OK auf ([SWS_Dcm_00840]).

Im Erfolgsfall werden die ausgelesenen Daten in den Puffer MemoryData geschrieben und DCM_READ_OK zurückgegeben ([SWS_Dcm_00539], [SWS_Dcm_00985]). Schlägt die Operation fehl, liefert die Funktion DCM_READ_FAILED zurück und setzt ErrorCode. Das DCM sendet daraufhin eine negative Antwort mit dem entsprechenden NRC-Wert ([SWS_Dcm_00644]).

Die in Dcm_Externals.h deklarierte Callout-Funktion Dcm_WriteMemory wird vom DCM asynchron und nicht-reentrant aufgerufen, um Speicherdaten anhand von Startadresse und Bytegröße zu schreiben [SWS_Dcm_00540]. Sie dient der Implementierung der UDS-Dienste WriteMemoryByAddress (0x3D), RequestDownload und TransferData [SWS_Dcm_00540]. Beim Empfang von WriteMemoryByAddress ruft das DCM den Callout erst nach Prüfung der Anfrage auf [SWS_Dcm_00491].

Zur Steuerung des Ablaufs wird OpStatus übergeben (mögliche Werte: DCM_INITIAL, DCM_PENDING, DCM_CANCEL oder DCM_FORCE_RCRRP_OK) [SWS_Dcm_00540]. Die Parameter MemoryAddress und MemorySize bestimmen den Zielspeicherbereich, während MemoryData auf den Diagnosepuffer des DCM zeigt [SWS_Dcm_00540]. Werden MemoryIdentifier oder MemoryAddress (beispielsweise bei komprimierten Daten) nicht genutzt, müssen diese auf 0 gesetzt werden [SWS_Dcm_00540].

Der Rückgabewert Dcm_ReturnWriteMemoryType [SWS_Dcm_00986] definiert die weitere Verarbeitung im DCM:

• DCM_WRITE_OK: Der Schreibvorgang war erfolgreich [SWS_Dcm_00540], [SWS_Dcm_00986].
• DCM_WRITE_PENDING: Die Operation ist noch nicht abgeschlossen und erfordert Folgeaufrufe [SWS_Dcm_00540], [SWS_Dcm_00986].
• DCM_WRITE_FORCE_RCRRP: Das DCM initiiert unverzüglich das Senden einer Response Pending (NRC 0x78) und setzt weitere Aufrufe bis zur Sendebestätigung aus [SWS_Dcm_00837]. Danach erfolgt der Neuaufruf aus Dcm_MainFunction mit DCM_FORCE_RCRRP_OK [SWS_Dcm_00838].
• DCM_WRITE_FAILED: Bei einem Fehler sendet das DCM eine negative Antwort mit dem über den Ausgabeparameter ErrorCode übergebenen NRC-Wert [SWS_Dcm_00540], [SWS_Dcm_00643].

Die Callout-Funktion Dcm_SetProgConditions ermöglicht dem Integrator das persistente Sichern relevanter Informationen vor einem Wechsel in den Bootloader oder einem Reset infolge einer ECUReset-Anforderung [SWS_Dcm_00543]. Die relevanten Kontextdaten werden über einen Zeiger auf die Struktur Dcm_ProgConditionsType übergeben, welche unter anderem Verbindungs- und Tester-Quelladressen, Dienst- und Subfunktions-IDs sowie Steuerungs-Flags wie ReprogramingRequest und ResponseRequired bündelt [SWS_Dcm_00988]. Bei Empfang eines UDS-Dienstes 0x10 mit Subfunktion 0x02 setzt das DCM diese Flags und ruft die Schnittstelle auf [SWS_Dcm_01182].

Der Aufruf erfolgt asynchron und ist nicht reentrant (Non Reentrant) [SWS_Dcm_00543]. Über den Parameter OpStatus werden die Zustände DCM_INITIAL, DCM_PENDING, DCM_CANCEL oder DCM_FORCE_RCRRP_OK gesteuert [SWS_Dcm_00543]. Sofern die Ausführung andauert und die Funktion DCM_E_PENDING zurückgibt, ruft das DCM die Schnittstelle im nächsten Hauptfunktionszyklus erneut auf, um das Setzen abzuschließen [SWS_Dcm_00543], [SWS_Dcm_01184]. Mittels DCM_E_FORCE_RCRRP kann die Übertragung einer Response-Pending-Antwort (NRC 0x78) erzwungen werden [SWS_Dcm_00543]. Abhängig von der Konfiguration erfolgt der Aufruf durch das DCM erst nach erfolgreicher Übertragung von NRC 0x78 [SWS_Dcm_00535].

Wurden die Bedingungen fehlerfrei gesetzt und liefert das Callout E_OK zurück, stößt das DCM den Moduswechsel des ModeDeclarationGroupPrototype DcmEcuReset nach EXECUTE an [SWS_Dcm_00719], [SWS_Dcm_01163], [SWS_Dcm_01180]. Kann der Zustand hingegen nicht gesichert werden und antwortet die Funktion mit E_NOT_OK, unterbleiben der Reset sowie der Bootloader-Sprung, der Moduswechsel wird unterbunden und das DCM sendet die negative Antwort NRC 0x22 (Conditions not correct) [SWS_Dcm_00715], [SWS_Dcm_01181].

Die Callout-Funktion Dcm_GetProgConditions mit der Service-ID 0x62 wird während der Initialisierung des DCM aufgerufen, um festzustellen, ob eine ausstehende Diagnoseantwort auf Dienst $50 oder $51 gesendet werden muss [SWS_Dcm_00544]. Die Deklaration der Schnittstelle wird über die Header-Datei Dcm_Externals.h bereitgestellt [SWS_Dcm_00544].

Verwendung und Parameter

Die Funktionsausführung erfolgt synchron, wobei keine regulären Eingabe- oder Ein-/Ausgabeparameter übergeben werden [SWS_Dcm_00544]:

• Ausgabeparameter: Über den Zeiger ProgConditions vom Typ Dcm_ProgConditionsType* liefert der Callout die Bedingungen zurück, unter denen der vorherige Sprung aus dem Bootloader angefordert wurde [SWS_Dcm_00544]. Die relevanten Kontextparameter sind im Datentyp Dcm_ProgConditionsType hinterlegt [SWS_Dcm_00544].
• Rückgabewert: Die Funktion gibt einen Statuswert vom Typ Dcm_EcuStartModeType an den Aufrufer zurück [SWS_Dcm_00544].

Nebenläufigkeit und Fehlerbehandlung

Die Funktion ist als nicht reentrant (Non Reentrant) eingestuft und darf daher nicht nebenläufig ausgeführt werden [SWS_Dcm_00544]. Für diesen Callout sind in der Schnittstellenspezifikation keine spezifischen Fehlercodes für DET oder DEM definiert [SWS_Dcm_00544].

Die Callout-Funktion Dcm_ProcessRequestAddFile wird vom DCM aufgerufen, um den Dienst RequestFileTransfer mit der Betriebsart 0x01 (AddFile) zu initiieren ([SWS_Dcm_91078]). Sie ist über Dcm_Externals.h verfügbar, besitzt die Service-ID 0x72 und ist als nicht reentrant (Non Reentrant) sowie asynchron spezifiziert ([SWS_Dcm_91078]).

Die Steuerung des asynchronen Aufrufablaufs erfolgt über den Parameter OpStatus:

• DCM_INITIAL: Alle Eingangsparameter sind gültig. Hierzu zählen Dateipfad und -name (filePathAndName mit filePathAndNameLength), das Byte dataFormatIdentifier (High-Nibble für Kompression, Low-Nibble für Verschlüsselung) sowie die unkomprimierte und komprimierte Dateigröße (fileSizeUncompressed, fileSizeCompressed) ([SWS_Dcm_91078]).
• DCM_PENDING, DCM_CANCEL und DCM_FORCE_RCRRP_OK: In diesen Folgeaufrufen sind sämtliche Eingangsparameter auf 0x00 gesetzt ([SWS_Dcm_91078]).

Als Rückgabewerte liefert die Funktion E_OK bei erfolgreicher Ausführung, DCM_E_PENDING bei andauernder Bearbeitung oder DCM_E_FORCE_RCRRP, wenn die Applikation das Senden einer vorläufigen Antwort (NRC 0x78) anfordert ([SWS_Dcm_91078], [SWS_Dcm_91086]). Im Erfolgsfall definiert maxNumberOfBlockLength die maximal zulässige Blocklänge künftiger TransferData-Nachrichten ohne SID und Block-Zähler ([SWS_Dcm_91078]).

Im Fehlerfall liefert die Funktion E_NOT_OK zurück. In diesem Fall muss über den Parameter ErrorCode ein negativer Antwortcode (NRC) übergeben werden, den das DCM in einer negativen Diagnoseantwort an den Client sendet ([SWS_Dcm_91078]). Ist die Konfiguration DcmRequestFileTransferUsePort aktiviert, wird diese Funktionalität alternativ als Port-Operation ProcessRequestAddFile des Interfaces RequestFileTransfer bereitgestellt ([SWS_Dcm_91086]).

Verwendung und Aufrufsemantik

Die Callout-Funktion Dcm_ProcessRequestDeleteFile wird vom DCM aufgerufen, um im Rahmen des Diagnose-Dienstes RequestFileTransfer das Löschen einer Datei (modeOfOperation = 0x02) auf dem Server zu initiieren [SWS_Dcm_91079]. Die Funktion ist in Dcm_Externals.h deklariert und arbeitet asynchron sowie nicht reentrant (Non Reentrant) [SWS_Dcm_91079].

Die Übergabe und Auswertung erfolgt anhand des Parameters OpStatus:

• DCM_INITIAL: Zeigt den Start der Operation an. Hierbei sind alle Eingangsparameter gültig; filePathAndName übergibt den Speicherort und Namen der zu löschenden Datei, dessen Bytelänge über filePathAndNameLength spezifiziert ist [SWS_Dcm_91079].
• DCM_PENDING, DCM_CANCEL oder DCM_FORCE_RCRRP_OK: Bei fortlaufender Verarbeitung oder Abbruch sind alle Eingangsparameter auf 0x00 gesetzt [SWS_Dcm_91079].

Als Rückgabewerte liefert die Funktion E_OK bei erfolgreicher Durchführung, DCM_E_PENDING, falls die Ausführung noch andauert und weitere Aufrufe benötigt, oder DCM_E_FORCE_RCRRP, wenn die Applikation das Senden einer Zwischennachricht mit NRC 0x78 (Response Pending) anfordert [SWS_Dcm_91079], analog zum Dienst RequestFileTransfer [SWS_Dcm_91086].

Fehlerbehandlung

Schlägt die Verarbeitung fehl, gibt die Funktion E_NOT_OK zurück. In diesem Fall muss über den Ausgabeparameter ErrorCode ein negativer Antwortcode bereitgestellt werden, den das DCM als negative Rückmeldung (NRC) an den Tester übermittelt [SWS_Dcm_91079].

Die Callout-Funktion Dcm_ProcessRequestReplaceFile wird vom DCM aufgerufen, um einen Diagnoseprozess für RequestFileTransfer mit der Betriebsart 0x03 (ReplaceFile) zu initiieren [SWS_Dcm_91080]. Die Funktion ist als nicht reentrant (Non Reentrant) und asynchron definiert und wird über den Header Dcm_Externals.h bereitgestellt [SWS_Dcm_91080].

Die Steuerung des asynchronen Verarbeitungsablaufs erfolgt über den Parameter OpStatus:

• Beim Initialaufruf mit DCM_INITIAL übergibt das DCM alle Eingabeparameter gültig, darunter Pfad und Dateiname (filePathAndName mit Längenangabe filePathAndNameLength), die Kennung für Kompression und Verschlüsselung (dataFormatIdentifier) sowie die unkomprimierte und komprimierte Dateigröße (fileSizeUncompressed, fileSizeCompressed) [SWS_Dcm_91080].
• Bei Folgeaufrufen oder einem Abbruch (DCM_PENDING, DCM_CANCEL, DCM_FORCE_RCRRP_OK) sind alle In-Parameter auf 0x00 gesetzt [SWS_Dcm_91080].
• Im Erfolgsfall gibt die Funktion über den Out-Parameter maxNumberOfBlockLength die maximale Nutzdatenlänge für nachfolgende TransferData-Anfragen (ohne SID und Blockfolgezähler) an das DCM zurück [SWS_Dcm_91080].

Als Rückgabewerte sind E_OK bei erfolgreicher Ausführung, DCM_E_PENDING bei noch andauernder Bearbeitung sowie DCM_E_FORCE_RCRRP zum Anfordern einer Response-Pending-Rückmeldung (NRC 0x78) vorgesehen [SWS_Dcm_91080], [SWS_Dcm_91086]. Schlägt die Ausführung fehl, gibt die Funktion E_NOT_OK zurück und weist dem Parameter ErrorCode den entsprechenden negativen Diagnoseantwortcode (NRC) zu, den das DCM an den Tester übermittelt [SWS_Dcm_91080].

Die Callout-Funktion Dcm_ProcessRequestReadFile wird vom DCM aufgerufen, um einen File-Transfer-Prozess (Service RequestFileTransfer) mit der Betriebsart ReadFile (modeOfOperation 0x04) zu starten [SWS_Dcm_91081]. Die Funktion ist im Header Dcm_Externals.h deklariert, arbeitet asynchron und ist nicht reentrant (Non Reentrant) [SWS_Dcm_91081].

Der Aufruf erfolgt über den Statusparameter OpStatus: Beim Initialaufruf DCM_INITIAL sind alle Eingabeparameter gültig, während sie bei Folgeaufrufen mit DCM_PENDING, DCM_CANCEL oder DCM_FORCE_RCRRP_OK auf 0x00 gesetzt werden [SWS_Dcm_91081]. Die Anwendung erhält Pfad und Dateinamen über filePathAndName (Länge in filePathAndNameLength), das Format zur Kompression und Verschlüsselung über dataFormatIdentifier sowie die Dateigrößen über fileSizeUncompressed und fileSizeCompressed [SWS_Dcm_91081]. Als Ausgabeparameter muss die Anwendung maxNumberOfBlockLength mit der maximalen Byte-Anzahl für nachfolgende TransferData-Antworten (ohne SID und Block-Sequenzzähler) belegen [SWS_Dcm_91081].

Als Rückgabewerte von Std_ReturnType sind E_OK bei erfolgreicher Ausführung, DCM_E_PENDING bei noch andauernder asynchroner Verarbeitung oder DCM_E_FORCE_RCRRP zur Anforderung einer „Response Pending“-Antwort (NRC 0x78) definiert [SWS_Dcm_91081]. Schlägt die Operation fehl, liefert sie E_NOT_OK; in diesem Fall übermittelt das DCM eine negative Antwort mit dem im Ausgabeparameter ErrorCode gesetzten NRC-Wert an den Tester [SWS_Dcm_91081]. Das Zusammenspiel entspricht der allgemeinen Abwicklung des Dienstes RequestFileTransfer, wie er analog für andere Dateioperationen wie ProcessRequestAddFile konfiguriert wird [SWS_Dcm_91086].

Verwendung

Die Callout-Funktion Dcm_ProcessRequestReadDir wird über die Header-Datei Dcm_Externals.h deklariert und vom DCM aufgerufen, um den Dienst RequestFileTransfer mit dem Betriebsmodus 0x05 (ReadDir) asynchron zu starten [SWS_Dcm_91082]. Der Verarbeitungsfortschritt wird über den Übergabeparameter OpStatus gesteuert [SWS_Dcm_91082]. Beim Erstaufruf mit DCM_INITIAL übergibt das DCM den Pfad bzw. Namen über filePathAndName zusammen mit der Byte-Länge filePathAndNameLength [SWS_Dcm_91082]. Bei nachfolgenden Aufrufen oder bei einem Abbruch (DCM_PENDING, DCM_CANCEL, DCM_FORCE_RCRRP_OK) sind alle Eingangsparameter auf 0x00 gesetzt [SWS_Dcm_91082].

Als Ausgabewerte muss die Anwendung die Größe der Verzeichnisdaten über dirInfoLength und die maximal zulässige Blockgröße für nachfolgende Übertragungen über maxNumberOfBlockLength bereitstellen [SWS_Dcm_91082]. Neben E_OK bei erfolgreicher Ausführung kann die Funktion DCM_E_PENDING zurückgeben, wenn die Operation noch andauert, oder DCM_E_FORCE_RCRRP, um das Senden einer Zwischenantwort (NRC 0x78) zu veranlassen [SWS_Dcm_91082].

Fehlerbehandlung

Tritt ein Fehler auf, muss die Funktion E_NOT_OK zurückgeben. In diesem Fall liest das DCM den Parameter ErrorCode aus und übermittelt dessen Wert als negativen Antwortcode (NRC) an den Tester [SWS_Dcm_91082]. Spezifische DET- oder DEM-Meldungen sind für die Schnittstelle nicht vorgesehen; Fehlerprüfungen des übergebenen Pfads dürften daher vollständig der anwendungsspezifischen Implementierung obliegen. Frage Q-278dbc3db7b4363b (offen)

Nebenläufigkeit und Zusammenspiel

Die Funktion ist als nicht reentrant (Non Reentrant) spezifiziert und darf folglich nicht nebenläufig für mehrere Diagnoseanfragen aufgerufen werden [SWS_Dcm_91082]. Sie ist Teil der Schnittstellengruppe des Dienstes RequestFileTransfer, dessen Anbindung über Konfigurationsparameter beeinflusst werden kann [SWS_Dcm_91086].

Verwendung und Aufrufkontext

Die Callout-Funktion Dcm_WriteFile wird vom DCM aufgerufen, wenn über den UDS-Dienst TransferData (0x36) Daten empfangen werden und ein zuvor mittels RequestFileTransfer mit den Modi 0x01 (AddFile) oder 0x03 (ReplaceFile) gestarteter Download-Prozess aktiv ist [SWS_Dcm_01444]. Die Schnittstelle ist über Dcm_Externals.h verfügbar [SWS_Dcm_91083].

Die Parameterbelegung hängt vom Fortschrittsstatus OpStatus ab [SWS_Dcm_91083]:

• DCM_INITIAL: Alle Eingangsparameter sind gültig. Der Zeiger Data verweist auf die zu schreibenden Nutzdaten, und DataLength gibt deren Bytelänge an. Der Wert von DataLength überschreitet nicht die zuvor bei Dcm_ProcessRequestFileTransfer ausgehandelte maximale Blocklänge (NumberOfBlockLength).
• DCM_PENDING, DCM_CANCEL und DCM_FORCE_RCRRP_OK: Alle Eingangsparameter sind auf 0x00 gesetzt.

Asynchrone Semantik und Rückgabewerte

Die Funktion arbeitet asynchron und nicht-reentrant (Non Reentrant) [SWS_Dcm_91083]. Sie liefert folgende Statuswerte:

• E_OK: Der Schreibvorgang wurde erfolgreich abgeschlossen.
• DCM_E_PENDING: Die Verarbeitung ist noch nicht beendet und erfordert weitere Aufrufe.
• DCM_E_FORCE_RCRRP: Die Applikation fordert das Senden einer Warteantwort (Response Pending, NRC 0x78) an.
• E_NOT_OK: Die Operation ist fehlgeschlagen.

Fehlerbehandlung

Gibt Dcm_WriteFile den Wert E_NOT_OK zurück, sendet das DCM-Modul eine negative UDS-Antwort, deren NRC dem über den Ausgabeparameter ErrorCode bereitgestellten Wert entspricht [SWS_Dcm_91083].

Die Callout-Funktion Dcm_ReadFileOrDir wird vom DCM-Modul aufgerufen, wenn im Rahmen eines laufenden Datei- oder Verzeichnis-Uploads (zuvor gestartet via UDS-Dienst RequestFileTransfer mit Modus 0x04 für ReadFile oder 0x05 für ReadDir) eine formatkonforme Anfrage für den UDS-Dienst TransferData (0x36) eingeht [SWS_Dcm_01445]. Die Funktion dient dazu, die als Antwort an den Client zu sendenden Daten bereitzustellen [SWS_Dcm_91085]. Die Schnittstellendeklaration ist über den Header Dcm_Externals.h verfügbar [SWS_Dcm_91085].

Die Ausführung erfolgt asynchron und ist als nicht reentrant (Non Reentrant) spezifiziert [SWS_Dcm_91085]. Das Zusammenspiel und die Parameterbelegung hängen vom übergebenen Betriebsstatus ab:

• Betriebsstatus (OpStatus): Beim initialen Aufruf mit DCM_INITIAL sind alle Eingangsparameter gültig. Bei Folge- oder Abbruchaufrufen mit DCM_PENDING, DCM_CANCEL oder DCM_FORCE_RCRRP_OK sind alle Eingangsparameter auf 0x00 gesetzt [SWS_Dcm_91085].
• Puffer und Blocklänge: Der Parameter DataLength übergibt eingangsseitig die maximal zulässige Blocklänge (entsprechend dem dem Client gemeldeten Wert maxNumberOfBlockLength) und gibt ausgangsseitig die tatsächlich in Data bereitgestellte Bytelänge zurück, die den Eingangswert nicht überschreiten darf [SWS_Dcm_91085]. Interpretation: Obwohl Data in der Schnittstelle formal als In-Parameter deklariert ist, dürfte er zur Übergabe der auszulesenden Nutzdaten dienen. Frage Q-53de8a0bdbc4a2b4 (offen)
• Rückgabewerte: Die Operation liefert E_OK bei erfolgreicher Datenbereitstellung, DCM_E_PENDING bei noch nicht abgeschlossener Verarbeitung oder DCM_E_FORCE_RCRRP, wenn die Applikation das Versenden einer Zwischenmeldung (Response Pending, NRC 0x78) erzwingen möchte [SWS_Dcm_91085].

Schlägt die Verarbeitung in der Applikation fehl, wird E_NOT_OK zurückgegeben. In diesem Fehlerfall übermittelt das DCM-Modul eine negative UDS-Antwort (NRC) an den Client, deren Fehlercode dem im Ausgabeparameter ErrorCode gesetzten Wert entspricht [SWS_Dcm_91085].

Die Funktion Dcm_MainFunction dient der Abarbeitung der zentralen Aufgaben der Hauptschleife des Diagnostic Communication Managers ([SWS_Dcm_00053]). Sie besitzt die Signatur void Dcm_MainFunction(void) und liefert keine Rückgabewerte. Da sie über den Header SchM_Dcm.h bereitgestellt wird, dürfte ihr Aufruf vermutlich zyklisch im Kontext einer Scheduler-Task der Basissoftware erfolgen. Frage Q-e083a72aae447ab5 (offen)

Eine wesentliche Aufgabe ist die Steuerung und zyklusübergreifende Weiterführung asynchroner Abläufe:

• Liefert eine Operation mit Dcm_OpStatusType den Rückgabewert DCM_E_PENDING, ruft das DCM die Operation bei jedem Aufruf von Dcm_MainFunction mit OpStatus = DCM_PENDING erneut auf, solange dieser Status anhält ([SWS_Dcm_00530]).
• Gibt Dem_ClearDTC() den Status DEM_PENDING zurück, wird die Funktion im nächsten Zyklus von Dcm_MainFunction erneut aufgerufen; das DCM sendet bei Bedarf NRC 78 (ResponsePending) ([SWS_Dcm_00703]).
• Aufrufe von Dem_SetDTCFilter() mit gesetztem Parameter FilterForFault-DetectionCounter müssen zwingend im Kontext von Dcm_MainFunction erfolgen ([SWS_Dcm_00519]).
• Nach Bestätigung einer RCR-RP-Übertragung ruft das DCM Operationen wie Dcm_WriteMemory oder Dcm_ReadMemory aus Dcm_MainFunction erneut mit OpStatus = DCM_FORCE_RCRRP_OK auf ([SWS_Dcm_00529], [SWS_Dcm_00838], [SWS_Dcm_00840]).
• Wird bei Xxx_GetSecurityAttemptCounter der Wert DCM_E_PENDING gemeldet, wird der Aufruf unterbrochen und im nächsten Zyklus fortgesetzt ([SWS_Dcm_01351]); bei Überschreiten des konfigurierten Timeouts bricht das DCM die anhängige Operation mit OpStatus = DCM_CANCEL ab ([SWS_Dcm_01352]).

Die Funktion Xxx_GetSeed (bereitgestellt über Dcm_Externals.h) dient der asynchronen Bereitstellung eines Seed-Werts durch die Applikation für das DCM-Modul [SWS_Dcm_01151]. Sie wird aufgerufen, sobald eine UDS-Anfrage des Dienstes SecurityAccess (0x27) mit dem Subfunktionstyp „requestSeed“ empfangen wird und die angeforderte Sicherheitsstufe noch nicht aktiv ist [SWS_Dcm_00862], [SWS_Dcm_00324].

Aufrufkontext und Parameter

Die Schnittstelle ist als nicht reentrant (Non Reentrant) definiert und operiert asynchron [SWS_Dcm_01151]:

• SecurityAccessDataRecord: Zeiger auf zusätzliche Eingangsdaten zur Seed-Berechnung; die Mindestgröße beträgt ein Byte gemäß DcmDspSecurityADRSize [SWS_Dcm_01151].
• OpStatus: Gibt den aktuellen Status der asynchronen Operation an [SWS_Dcm_01151].
• Seed: Ausgabepointer, über den die Applikation den berechneten Seed bereitstellt [SWS_Dcm_01151].
• ErrorCode: Ausgabeparameter zur Rückgabe eines negativen Fehlercodes (NRC) [SWS_Dcm_01151].

Rückgabewerte und Fehlerbehandlung

• E_OK: Der Seed wurde erfolgreich ermittelt und bereitgestellt [SWS_Dcm_01151].
• DCM_E_PENDING: Die Berechnung ist noch nicht abgeschlossen; zur Fertigstellung sind Folgeberechnungen bzw. -aufrufe notwendig [SWS_Dcm_01151].
• E_NOT_OK: Die Anfrage schlug fehl. In diesem Fall sendet das DCM-Modul eine negative UDS-Antwort mit dem im Parameter ErrorCode übergebenen NRC-Wert [SWS_Dcm_01151], [SWS_Dcm_00659].

Integrationshinweise

Je nach Konfiguration von DcmDspSecurityUsePort erfolgt die Anbindung als C-Funktion bei USE_ASYNCH_FNC (referenziert über DcmDspSecurityGetSeedFnc) [SWS_Dcm_00862] oder als Rte-Operation bei USE_ASYNCH_CLIENT_SERVER [SWS_Dcm_00324]. Sofern keine zusätzlichen Zugangsdaten übergeben werden müssen, kommt die alternative Funktionssignatur ohne den Parameter SecurityAccessDataRecord zum Einsatz [SWS_Dcm_91003].

Die Funktion Xxx_GetSeed dient als asynchrone Schnittstelle des Moduls DCM an die Applikation, um im Rahmen des UDS-Dienstes SecurityAccess (0x27) bei einer Anfrage vom Typ „requestSeed“ einen Seed-Wert bereitzustellen [SWS_Dcm_91003], [SWS_Dcm_00862]. Der Aufruf erfolgt durch das DCM-DSP-Submodul, sofern die Sicherheitsstufe noch nicht aktiv ist und die Konfiguration USE_ASYNCH_CLIENT_SERVER oder USE_ASYNCH_FNC vorsieht [SWS_Dcm_00324], [SWS_Dcm_00862].

Die Schnittstelle ist asynchron und nicht reentrant (Non Reentrant) ausgeführt [SWS_Dcm_91003]. Die Steuerung des Verarbeitungsfortschritts erfolgt über den Eingangsparameter OpStatus (Typ Dcm_OpStatusType) [SWS_Dcm_91003]. Als Rückgabewerte sind E_OK bei erfolgreicher Bereitstellung, E_NOT_OK im Fehlerfall sowie DCM_E_PENDING definiert, wenn die Seed-Generierung noch andauert und weitere Aufrufe erforderlich sind [SWS_Dcm_91003]. Der generierte Wert wird über den Zeiger Seed (Inout/Out-Puffer) übergeben [SWS_Dcm_91003].

Schlägt die Operation fehl und Xxx_GetSeed liefert E_NOT_OK zurück, muss das DCM-Modul eine negative Antwort (NRC) mit dem Fehlercode versenden, der über den Ausgabeparameter ErrorCode (Dcm_NegativeResponseCodeType) gesetzt wurde [SWS_Dcm_91003], [SWS_Dcm_00659]. Deklariert ist der Dienst über den Header Dcm_Externals.h [SWS_Dcm_91003].

Die Funktion Xxx_CompareKey wird vom Diagnostic Communication Manager ([SWS_Dcm_91004]) asynchron und nicht-reentrant aufgerufen, um einen empfangenen Schlüssel im Rahmen des UDS-Dienstes SecurityAccess (0x27, Subfunktion sendKey) gegen die interne Logik der Applikation abzugleichen ([SWS_Dcm_00863]). Sie kommt zum Einsatz, wenn der Zugriffsstatus noch nicht aktiv ist, die Seed-Anfrage erfolgreich war und der Konfigurationsparameter DcmDspSecurityUsePort auf USE_ASYNCH_CLIENT_SERVER gesetzt ist ([SWS_Dcm_00324]) bzw. laut [SWS_Dcm_00863] die Funktionsschnittstelle über USE_ASYNCH_FNC/DcmDspSecurityCompareKeyFnc konfiguriert wurde. Deklariert ist die Schnittstelle in Dcm_Externals.h ([SWS_Dcm_91004]).

Die Übergabe umfasst den zu prüfenden Schlüsselzeiger Key, den aktuellen Operationsstatus OpStatus (vom Typ Dcm_OpStatusType) sowie den Zeiger ErrorCode für den im Fehlerfall auszugebenden negativen Antwortcode ([SWS_Dcm_91004]). Als Rückgabewerte sind spezifiziert:

• E_OK: Schlüsselprüfung erfolgreich ([SWS_Dcm_91004]).
• DCM_E_PENDING: Prüfung noch nicht abgeschlossen; weitere Aufrufe durch das DCM-Modul zur Beendigung sind erforderlich ([SWS_Dcm_91004]).
• E_NOT_OK: Verarbeitung nicht erfolgreich. Der DCM sendet daraufhin eine negative UDS-Antwort mit dem in ErrorCode gesetzten NRC, ohne den internen Sicherheitslevel zu verändern oder den Fehlversuchszähler (AttemptCounter) zu erhöhen ([SWS_Dcm_01150]).
• DCM_E_COMPARE_KEY_FAILED: Schlüssel stimmt nicht überein ([SWS_Dcm_91004]).

Schlägt der Schlüsselvergleich fehl (DCM_E_COMPARE_KEY_FAILED), wird bei konfiguriertem DcmDspSecurityNumAttDelay der AttemptCounter inkrementiert ([SWS_Dcm_01397]). Liegt der Zähler unterhalb des Grenzwerts, sendet der DCM den NRC 0x35 (InvalidKey) ([SWS_Dcm_00660]). Erreicht oder überschreitet die Anzahl der Fehlversuche das konfigurierte Limit DcmDspSecurityNumAttDelay, startet der DCM den SecurityDelayTimer mit der Zeitdauer DcmDspSecurityDelayTime und sendet den NRC 0x36 (exceededNumberOfAttempts) ([SWS_Dcm_01349]). In beiden Fällen verbleibt der Sicherheitslevel unverändert.

Die asynchrone und nicht-reentrante Funktion [SWS_Dcm_01152] liest bei der Initialisierung des DCM den aktuellen Fehlversuchszähler für eine konfigurierte Sicherheitsstufe aus der Applikation aus. Der Aufruf erfolgt für jeden Eintrag in DcmDspSecurityRow, bei dem der Konfigurationsparameter DcmDspSecurityAttemptCounterEnabled auf TRUE gesetzt ist [SWS_Dcm_01154].

Die Ablaufsteuerung wird über den Parameter OpStatus mit den Werten DCM_INITIAL, DCM_PENDING oder DCM_CANCEL geführt [SWS_Dcm_01152]. Gibt die Funktion DCM_E_PENDING zurück, unterbricht das DCM die Aufrufkette und setzt sie im darauffolgenden Zyklus von Dcm_MainFunction() fort [SWS_Dcm_01351]. Wird die nach dem ersten Zyklus konfigurierte Zeitüberwachung DcmDspSecurityMaxAttemptCounterReadoutTime überschritten, bricht das DCM den noch ausstehenden Vorgang mit DCM_CANCEL ab [SWS_Dcm_01352].

Im Erfolgsfall liefert die Schnittstelle E_OK und übergibt den Zählerstand über den Ausgabeparameter AttemptCounter [SWS_Dcm_01152]. Gibt der Aufruf E_NOT_OK zurück, setzt das DCM den Zähler automatisch auf den für diese Sicherheitsstufe konfigurierten Wert DcmDspSecurityNumAttDelay [SWS_Dcm_01156].

Solange nicht alle Zählerwerte endgültig ermittelt oder abgebrochen wurden, weist das DCM jede Anfrage auf SecurityAccess (0x27) zum Anfordern eines Seeds mit dem negativen Antwortcode conditionsNotCorrect (0x22) ab [SWS_Dcm_01354]. Nach Abschluss der Abfragekette prüft das DCM die Zählerwerte: Erreicht oder überschreitet mindestens ein Zähler den Schwellenwert DcmDspSecurityNumAttDelay, startet das DCM den SecurityDelayTimer mit dem höheren Wert aus DcmDspSecurityDelayTimeOnBoot und DcmDspSecurityDelayTime [SWS_Dcm_01355].

Die Funktion Xxx_SetSecurityAttemptCounter dient dazu, den Versuchszähler für eine spezifische Sicherheitsstufe in der Applikation zu setzen ([SWS_Dcm_01153]). Sie wird über den Header Dcm_Externals.h bereitgestellt.

Aufruf und Semantik

Die Ausführung erfolgt asynchron und ist als nicht reentrant (Non Reentrant) spezifiziert ([SWS_Dcm_01153]). Der Aufruf steuert den Ablauf über den Parameter OpStatus mit den Werten DCM_INITIAL, DCM_PENDING oder DCM_CANCEL. Der neue Zählerwert wird über den Eingangsparameter AttemptCounter (uint8) übergeben.

Rückgabewerte und Fehlerbehandlung

Als Rückgabetyp wird Std_ReturnType verwendet ([SWS_Dcm_01153]):

• E_OK: Die Anforderung wurde erfolgreich abgeschlossen.
• E_NOT_OK: Die Ausführung war nicht erfolgreich.
• DCM_E_PENDING: Die Verarbeitung ist noch nicht beendet; weitere Aufrufe zur Fertigstellung sind erforderlich.

Wird eine laufende asynchrone Operation abgebrochen, übergibt das DCM den Status DCM_CANCEL ([SWS_Dcm_01153]).

Zusammenspiel und Randbedingungen

Das DCM-Modul ruft Xxx_SetSecurityAttemptCounter auf, sobald es den Versuchszähler verändert hat, um die Applikation über die Aktualisierung zu benachrichtigen ([SWS_Dcm_01155]). Dies setzt voraus, dass der Konfigurationsparameter DcmDspSecurityAttemptCounterEnabled für die zugehörige DcmDspSecurityRow auf TRUE konfiguriert ist ([SWS_Dcm_01155]). Da die Schnittstelle nicht reentrant ist, muss die Applikation eine nebenläufige Ausführung für dieselbe Instanz ausschließen ([SWS_Dcm_01153]).

Die synchrone Funktion Xxx_ReadData fordert von der Applikation den aktuellen Datenwert eines DID oder PID an, wenn der Konfigurationsparameter DcmDspDataUsePort auf USE_DATA_SYNCH_CLIENT_SERVER eingestellt ist [SWS_Dcm_00793]. Die Schnittstelle wird über den Header Dcm_Externals.h bereitgestellt und besitzt die Service-ID 0x34 [SWS_Dcm_00793]. Die aufgerufene Applikation kopiert die angeforderten Nutzdaten direkt in den übergebenen Puffer Data [SWS_Dcm_00793].

Hinsichtlich des Rückgabewerts ist festgelegt, dass der Aufruf ausnahmslos E_OK zurückliefert [SWS_Dcm_00793]. Spezifische Fehlercodes, negative Rückmeldungen oder DET-/DEM-Meldungen sind für diese Signatur nicht spezifiziert. Interpretation: Ein Fehlschlagen der Datenbereitstellung ist auf dieser Schnittstellenebene vermutlich nicht vorgesehen, da im Gegensatz zur asynchronen Variante [SWS_Dcm_91005] weder ein Parameter ErrorCode für negative Antwortcodes (NRC) noch Rückgabewerte wie E_NOT_OK oder DCM_E_PENDING existieren. Frage Q-adcf0171ecfd37c4 (offen)

Bezüglich Nebenläufigkeit und Randbedingungen ist die Funktion als nicht reentrant (Non Reentrant) spezifiziert und arbeitet vollständig synchron [SWS_Dcm_00793]. Das Zusammenspiel mit Diagnoseanfragen erfolgt in mehreren Szenarien:

• Beim Empfang einer OBD-Service-$01-Anfrage mit Nicht-Verfügbarkeits-PIDs ruft das DCM die jeweils konfigurierten Xxx_ReadData-Funktionen für alle Daten des PIDs auf, um die Antwortwerte zu erfassen [SWS_Dcm_00408].
• Bei einer UDS-Anfrage des Dienstes 0x22 (ReadDataByIdentifier) mit Nicht-Verfügbarkeits-Identifiern ruft das DCM die Funktionen für alle Daten des OBDDataIdentifier [SWS_Dcm_01380] sowie des OBDInfoTypeDataIdentifier [SWS_Dcm_01389] auf.
• Wird hingegen ein asynchrones Verhalten benötigt, greifen die separaten Signaturen mit OpStatus gemäß [SWS_Dcm_91006] bzw. [SWS_Dcm_91005].

Die Funktion Xxx_ReadData dient dazu, Datenwerte eines DID oder PID asynchron von der Anwendung abzufragen, sofern der Parameter DcmDspDataUsePort auf USE_DATA_ASYNCH_CLIENT_SERVER konfiguriert ist ([SWS_Dcm_91006]). Sie wird über die Header-Datei Dcm_Externals.h deklariert ([SWS_Dcm_91006]).

Beim Aufruf steuert der Parameter OpStatus (Typ Dcm_OpStatusType) den Fortschritt der laufenden Operation, während über den Zeiger Data (Typ uint8*) der Ausgabepuffer übergeben wird, in den die angeforderten Daten zu kopieren sind ([SWS_Dcm_91006]). Als Rückgabewerte sind E_OK bei erfolgreichem Abschluss und DCM_E_PENDING definiert, sofern die Verarbeitung noch andauert und weitere Aufrufe zur Fertigstellung benötigt ([SWS_Dcm_91006]).

Das DCM-Modul bindet diese Funktion in folgende Diagnoseabläufe ein:

• Beim Empfang eines OBD Service $01 liest das DCM die aktuellen PID-Werte (ausgenommen Verfügbarkeits-PIDs) über die konfigurierten Xxx_ReadData-Funktionen ein ([SWS_Dcm_00408]).
• Bei UDS Service 0x22 (ReadDataByIdentifier) ruft das DCM die Funktion für OBDDataIdentifier ([SWS_Dcm_01380]) und OBDInfoTypeDataIdentifier ([SWS_Dcm_01389]) auf.

Hinsichtlich der Ausführung ist die Funktion als nicht reentrant (Non Reentrant) spezifiziert ([SWS_Dcm_91006]). Im Gegensatz zur synchronen Schnittstelle ([SWS_Dcm_00793]) oder der asynchronen Variante mit zusätzlichem ErrorCode-Parameter ([SWS_Dcm_91005]) sieht diese Funktionsausprägung keine direkte Rückgabe eines negativen Antwortcodes vor.

Die Funktion Xxx_ReadData fordert von der Applikation asynchron den Datenwert eines DID oder PID an, sofern der Konfigurationsparameter DcmDspDataUsePort auf USE_DATA_ASYNCH_CLIENT_SERVER eingestellt ist [SWS_Dcm_91005]. Die Funktionsdeklaration wird über die Schnittstellendatei Dcm_Externals.h bereitgestellt [SWS_Dcm_91005].

Die Schnittstelle besitzt folgende Aufruf- und Ablaufcharakteristika:

• Semantik und Parameter: Der Eingabeparameter OpStatus steuert den Fortschritt der laufenden Operation [SWS_Dcm_91005]. Bei erfolgreichem Abschluss werden die angeforderten Nutzdaten in den Ausgabepuffer Data kopiert und E_OK zurückgegeben [SWS_Dcm_91005]. Benötigt die Applikation weitere Bearbeitungszeit, signalisiert sie DCM_E_PENDING, woraufhin Folgebeschaltungen erforderlich sind [SWS_Dcm_91005].
• Fehlerbehandlung: Schlägt die Operation fehl und gibt E_NOT_OK zurück, wertet das DCM-Modul den Ausgabeparameter ErrorCode aus und sendet eine negative Diagnoseantwort mit diesem NRC-Code [SWS_Dcm_91005].
• Nebenläufigkeit: Die Funktion ist als nicht reentrant (Non Reentrant) definiert [SWS_Dcm_91005]. Interpretation: Die wiederholten Aufrufe bei anhängiger Bearbeitung dürften sequenziell im Zyklus der DCM-Hauptverarbeitung erfolgen. Frage Q-541226d5f242f7c2 (offen)
• Zusammenspiel: Das DCM-Modul ruft die Funktion bei Anfragen des OBD Service $01 für Nicht-Verfügbarkeits-PIDs [SWS_Dcm_00408] sowie beim UDS Service ReadDataByIdentifier (0x22) für OBDDataIdentifier [SWS_Dcm_01380] und OBDInfoTypeDataIdentifier [SWS_Dcm_01389] auf. Im Vergleich zur synchronen Variante [SWS_Dcm_00793] oder asynchronen Schnittstellen ohne NRC-Parameter [SWS_Dcm_91006] ermöglicht diese Signatur eine spezifische negative Fehlerübermittlung.

Verwendung

Die Funktion Xxx_WriteData wird vom Diagnostic Communication Manager (DCM) aufgerufen, um die Applikation zum Schreiben eines DID-Datenwerts (Data Identifier) aufzufordern ([SWS_Dcm_00794]). Die Deklaration wird über den Header Dcm_Externals.h bereitgestellt. Der Aufruf erfolgt synchron unter der Service-ID 0x51 ([SWS_Dcm_00794]).

Parameter und Rückgabewerte:

• Data (in): Zeiger auf den Puffer mit den zu schreibenden Nutzdaten ([SWS_Dcm_00794]).
• ErrorCode (out): Zeiger auf die Variable, in die bei einem Fehlschlag der negative Diagnosecode (NRC) einzutragen ist ([SWS_Dcm_00794]).
• Rückgabewert (Std_ReturnType): E_OK signalisiert erfolgreiches Schreiben, E_NOT_OK das Fehlschlagen der Operation ([SWS_Dcm_00794]).

Fehlerbehandlung

Gibt die Funktion E_NOT_OK zurück, liest das DCM-Modul den Parameter ErrorCode aus und sendet eine negative Diagnoseantwort mit diesem NRC-Code ([SWS_Dcm_00794]).

Nebenläufigkeit und Einschränkungen

Die Funktion ist als nicht reentrant (Non Reentrant) spezifiziert ([SWS_Dcm_00794]) und darf nicht nebenläufig ausgeführt werden.

Zusammenspiel

Da kein Längenparameter existiert, dürfte diese Variante für DIDs mit fester Datenlänge vorgesehen sein. Frage Q-ebc074ac1cb66aaa (offen) Für DIDs mit variabler Länge stellt AUTOSAR die synchrone Signatur mit dem Parameter DataLength bereit ([SWS_Dcm_91007]). Zudem existieren für langwierige Abläufe asynchrone Varianten mit OpStatus und möglicher Rückgabe von DCM_E_PENDING, sowohl mit fester Datenlänge ([SWS_Dcm_91008]) als auch mit variablem Längenparameter ([SWS_Dcm_91009]).

Die Callback-Funktion Xxx_WriteData dient dazu, die Applikation zum Schreiben des Datenwerts eines Data Identifier (DID) aufzufordern [SWS_Dcm_91007]. Die Schnittstelle ist über den Header Dcm_Externals.h deklariert und besitzt die Service-ID 0x52 [SWS_Dcm_91007]. Der Aufruf erfolgt synchron und ist als nicht reentrant (Non Reentrant) spezifiziert, weshalb keine nebenläufigen Aufrufe für dieselbe Funktion erfolgen dürfen [SWS_Dcm_91007].

An Parametern empfängt die Funktion den Puffer Data mit den zu schreibenden Nutzdaten sowie DataLength mit der Längenangabe in Bytes [SWS_Dcm_91007]. Als Rückgabewert liefert sie den Typ Std_ReturnType mit E_OK bei erfolgreicher Ausführung oder E_NOT_OK im Fehlerfall [SWS_Dcm_91007]. Schlägt die Operation fehl und gibt E_NOT_OK zurück, muss das DCM-Modul eine negative Antwort an den Diagnosetester senden; dabei entspricht der Negative Response Code (NRC) dem über den Zeigerparameter ErrorCode übermittelten Wert [SWS_Dcm_91007].

Im Gesamtsystem stellt [SWS_Dcm_91007] die synchrone Variante für DIDs mit expliziter Längenangabe dar. Ergänzend dazu existiert mit [SWS_Dcm_00794] (Service-ID 0x51) eine synchrone Variante ohne den Parameter DataLength. Für längere Schreibvorgänge sieht der Standard asynchrone Schnittstellen vor: [SWS_Dcm_91008] (Service-ID 0x35) ohne Längenangabe sowie [SWS_Dcm_91009] (Service-ID 0x3e) mit DataLength. Beide asynchronen Funktionen werden über OpStatus gesteuert und können neben E_OK und E_NOT_OK auch DCM_E_PENDING zurückgeben [SWS_Dcm_91008] [SWS_Dcm_91009].

Verwendung

Die Funktion Xxx_WriteData fordert die Applikation auf, den Datenwert eines Data Identifiers (DID) zu schreiben [SWS_Dcm_91008]. Sie ist in der Header-Datei Dcm_Externals.h deklariert und besitzt eine asynchrone Ausführungssemantik mit der Service-ID 0x35 [SWS_Dcm_91008].

Die Parameter und Rückgabewerte gliedern sich wie folgt [SWS_Dcm_91008]:

• Data (IN): Zeiger auf den Puffer, der die zu schreibenden Daten enthält.
• OpStatus (IN): Status der aktuellen Operation zur Steuerung des asynchronen Aufrufablaufs.
• ErrorCode (OUT): Zeiger auf den Fehlercode (NRC), der im Fehlerfall gesetzt wird.
• Rückgabewert (Std_ReturnType): E_OK bestätigt den erfolgreichen Schreibvorgang, E_NOT_OK meldet einen Fehlschlag und DCM_E_PENDING zeigt an, dass die Operation noch andauert und weitere Aufrufe zur Fertigstellung benötigt.

Fehlerbehandlung und Nebenläufigkeit

Gibt der Aufruf den Wert E_NOT_OK zurück, muss das DCM-Modul eine negative Antwort mit dem im Ausgabeparameter ErrorCode übergebenen NRC-Wert versenden [SWS_Dcm_91008]. Die Funktion ist als nicht reentrant spezifiziert [SWS_Dcm_91008], sodass gleichzeitige oder überlappende Aufrufe für dieselbe Instanz unzulässig sind.

Zusammenspiel und Varianten

Diese Schnittstelle nach [SWS_Dcm_91008] deckt den asynchronen Schreibzugriff ohne separaten Längenparameter ab. AUTOSAR definiert hierzu verwandte Varianten im DCM: eine synchrone Signatur ohne Längenangabe [SWS_Dcm_00794] sowie Signaturen mit zusätzlichem Parameter DataLength für synchrone [SWS_Dcm_91007] und asynchrone Abläufe [SWS_Dcm_91009].

Verwendung und Semantik

Die Funktion Xxx_WriteData fordert die Applikation dazu auf, den Datenwert eines Data Identifier (DID) zu schreiben [SWS_Dcm_91009]. Sie wird über die Header-Datei Dcm_Externals.h deklariert und besitzt die Service-ID 0x3e [SWS_Dcm_91009]. Die Ausführung erfolgt asynchron (Asynchronous), wozu folgende Parameter übergeben werden:

• Data (in): Zeiger auf den Puffer mit den zu schreibenden Nutzdaten [SWS_Dcm_91009].
• DataLength (in): Länge der zu schreibenden Daten in Byte [SWS_Dcm_91009].
• OpStatus (in): Operationsstatus (Dcm_OpStatusType) zur Steuerung des asynchronen Verarbeitungsfortschritts [SWS_Dcm_91009].
• ErrorCode (out): Zeiger zur Aufnahme eines negativen Antwortcodes (NRC) im Fehlerfall [SWS_Dcm_91009].

Als Rückgabewerte vom Typ Std_ReturnType sind E_OK (Schreibanforderung erfolgreich abgeschlossen), E_NOT_OK (Anforderung fehlgeschlagen) sowie DCM_E_PENDING definiert [SWS_Dcm_91009]. Der Status DCM_E_PENDING signalisiert, dass der Vorgang noch nicht beendet ist und weitere Folgeaufrufe zur Fertigstellung erforderlich sind [SWS_Dcm_91009]. Interpretation: Das DCM dürfte die Funktion bei Rückgabe von DCM_E_PENDING mit fortgeführtem OpStatus solange zyklisch erneut aufrufen, bis ein finales Ergebnis vorliegt. Frage Q-fdbd734dab052f5c (offen)

Fehlerbehandlung und Nebenläufigkeit

Gibt die Funktion den Wert E_NOT_OK zurück, muss über den Parameter ErrorCode der entsprechende Fehlercode bereitgestellt werden; das DCM-Modul sendet daraufhin eine negative Antwort mit diesem NRC-Wert [SWS_Dcm_91009]. Spezifische DET- oder DEM-Meldungen sind im Payload für diese Schnittstelle nicht definiert. Hinsichtlich Nebenläufigkeit ist die Funktion als nicht reentrant (Non Reentrant) spezifiziert [SWS_Dcm_91009].

Zusammenspiel und Schnittstellenvarianten

Die Signatur [SWS_Dcm_91009] deckt asynchrone Schreibzugriffe mit expliziter Längenangabe ab. Im DCM existieren weitere Varianten von Xxx_WriteData:

• Synchrone Ausführung ohne Längenangabe: [SWS_Dcm_00794] (Service-ID 0x51).
• Synchrone Ausführung mit Längenangabe: [SWS_Dcm_91007] (Service-ID 0x52).
• Asynchrone Ausführung ohne Längenangabe: [SWS_Dcm_91008] (Service-ID 0x35).

Verwendung

Mit der Funktion Xxx_ReadDataLength fordert das DCM-Modul die Applikation auf, die Datenlänge eines Datums in Byte zu ermitteln und zurückzuliefern [SWS_Dcm_00796]. Die Schnittstelle ist im Header Dcm_Externals.h deklariert und besitzt die Service-ID 0x36 [SWS_Dcm_00796]. Die Abfrage wird synchron ausgeführt [SWS_Dcm_00796]. Über den Ausgabeparameter DataLength vom Typ uint16* übergibt die Applikation die Bytelänge der zu lesenden Daten an das DCM [SWS_Dcm_00796]. Eingangs- oder Ein-/Ausgangsparameter sind nicht definiert [SWS_Dcm_00796]. Als Rückgabewert liefert die Funktion stets E_OK vom Typ Std_ReturnType [SWS_Dcm_00796].

Nebenläufigkeit und Einschränkungen

Die Schnittstelle ist als nicht reentrant (Non Reentrant) spezifiziert [SWS_Dcm_00796]. Da die Funktion synchron arbeitet und nach Spezifikation stets E_OK meldet, sind für diesen Aufruf keine spezifischen Fehlercodes oder abweichenden Statusrückgaben vorgesehen [SWS_Dcm_00796].

Zusammenspiel

Neben der synchronen Funktion existiert eine gleichnamige asynchrone Variante mit der Service-ID 0x4c, die ebenfalls über Dcm_Externals.h bereitgestellt wird [SWS_Dcm_91010]. Während die synchrone Fassung [SWS_Dcm_00796] ohne Operationsstatus auskommt, verlangt das asynchrone Gegenstück den Eingangsparameter OpStatus vom Typ Dcm_OpStatusType [SWS_Dcm_91010]. Zudem kann die asynchrone Schnittstelle neben E_OK den Rückgabewert DCM_E_PENDING liefern, falls die Anfrage noch nicht abgeschlossen ist und weitere Aufrufe zur Fertigstellung benötigt [SWS_Dcm_91010].

Die Funktion [SWS_Dcm_91010] (Service-ID 0x4c) fordert die Applikation auf, die Datenlänge eines Datenelements in Byte zu ermitteln. Sie ist im Header Dcm_Externals.h deklariert und dient dem Diagnostic Communication Manager (DCM) zur flexiblen Längenabfrage von Diagnosedaten.

Verwendung und Semantik

Beim Aufruf übergibt das DCM-Modul den aktuellen Fortschritt über den Eingangsparameter OpStatus vom Typ Dcm_OpStatusType ([SWS_Dcm_91010]). Das Ergebnis der Abfrage schreibt die Applikation in den Ausgabeparameter DataLength (Typ uint16*). Ist die Datenlänge nicht unmittelbar verfügbar, signalisiert die Funktion über den Rückgabewert DCM_E_PENDING, dass die Bearbeitung andauert und weitere Aufrufe erforderlich sind ([SWS_Dcm_91010]). Sobald das Ergebnis bereitsteht, meldet die Applikation den Abschluss mit E_OK zurück.

Nebenläufigkeit und Einschränkungen

Gemäß Spezifikation ist die Funktion als nicht reentrant eingestuft ([SWS_Dcm_91010]), weshalb gleichzeitige Aufrufe durch das DCM ausgeschlossen werden müssen. Da die Spezifikation keine spezifischen Fehlerwerte außer DCM_E_PENDING vorsieht, dürfte das DCM bei Rückgabe von E_OK stets von einer gültig gesetzten Bytegröße ausgehen. Frage Q-e7ecd3a518e2cbcb (offen)

Zusammenspiel

Die asynchrone Schnittstelle [SWS_Dcm_91010] unterscheidet sich von der verwandten synchronen Variante [SWS_Dcm_00796] (Service-ID 0x36). Letztere besitzt keinen Parameter OpStatus, wird synchron ausgeführt und liefert die Länge stets unmittelbar mit E_OK zurück. [SWS_Dcm_91010] erlaubt es der Applikation hingegen, zeitintensive Berechnungen asynchron über mehrere Aufrufzyklen zu strecken.

Die synchrone Callout-Funktion Xxx_ConditionCheckRead wird über die Header-Datei Dcm_Externals.h bereitgestellt und dient dazu, bei der Applikation abzufragen, ob die Bedingungen für das Auslesen der Diagnosedaten erfüllt sind [SWS_Dcm_00797].

Die Schnittstelle besitzt keine Eingangsparameter und signalisiert den Status der Prüfung über den Rückgabewert vom Typ Std_ReturnType [SWS_Dcm_00797]:

• E_OK: Die Prüfung war erfolgreich, die Bedingungen zum Lesen der Daten sind erfüllt [SWS_Dcm_00797].
• E_NOT_OK: Die Prüfung schlug fehl, das Auslesen ist nicht zulässig [SWS_Dcm_00797].

Liefert die Funktion E_NOT_OK zurück, sendet das DCM-Modul eine negative Antwort (Negative Response) mit dem Fehlercode, den die Applikation über den Ausgabeparameter ErrorCode (Typ Dcm_NegativeResponseCodeType*) übergeben hat [SWS_Dcm_00797].

Hinsichtlich der Nebenläufigkeit ist die Funktion als nicht reentrant (Non Reentrant) spezifiziert und wird mit der Service-ID 0x49 synchron ausgeführt [SWS_Dcm_00797]. Die Prüfung dürfte anwendungsseitig daher unmittelbar ohne blockierende Wartezeiten ausgewertet werden, um eine Verzögerung des synchronen DCM-Aufrufers zu vermeiden. Frage Q-ada29c78c29d961e (offen)

In Abgrenzung zu dieser synchronen Operation definiert [SWS_Dcm_91011] eine asynchrone Variante unter der Service-ID 0x37. Diese verwendet zusätzlich den Eingangsparameter OpStatus (Typ Dcm_OpStatusType) und kann neben E_OK und E_NOT_OK auch DCM_E_PENDING zurückgeben, wenn Folgeschritte zur Beendigung der Prüfung notwendig sind [SWS_Dcm_91011].

Verwendung und Semantik

Die Funktion Xxx_ConditionCheckRead wird über die Header-Datei Dcm_Externals.h bereitgestellt und dient dazu, bei der Anwendungssoftware abzufragen, ob die Bedingungen zum Auslesen der Diagnosedaten erfüllt sind [SWS_Dcm_91011]. Die Ausführung erfolgt unter der Service-ID 0x37 asynchron [SWS_Dcm_91011]. Über den Eingangsparameter OpStatus (Typ Dcm_OpStatusType) wird der aktuelle Status der laufenden Operation übergeben [SWS_Dcm_91011].

Rückgabewerte und Fehlerbehandlung

Als Rückgabewert liefert die Funktion einen Status vom Typ Std_ReturnType [SWS_Dcm_91011]:

• E_OK: Die Anfrage war erfolgreich und die Lesebedingungen sind erfüllt [SWS_Dcm_91011].
• E_NOT_OK: Die Prüfung schlug fehl [SWS_Dcm_91011]. In diesem Fall muss die Anwendung über den Ausgabeparameter ErrorCode einen negativen Antwortcode (NRC) vom Typ Dcm_NegativeResponseCodeType setzen; das DCM-Modul sendet daraufhin eine negative Antwort mit diesem NRC [SWS_Dcm_91011].
• DCM_E_PENDING: Die Prüfung ist noch nicht abgeschlossen, sodass weitere Aufrufe zur Fertigstellung erforderlich sind [SWS_Dcm_91011].

Nebenläufigkeit und Abgrenzung

Die Schnittstelle ist als nicht reentrant (Non Reentrant) spezifiziert [SWS_Dcm_91011]. Im Unterschied zu dieser asynchronen Variante definiert [SWS_Dcm_00797] unter der Service-ID 0x49 eine synchrone Signatur ohne OpStatus-Parameter, welche ausschließlich E_OK oder E_NOT_OK zurückliefert [SWS_Dcm_00797].

Die asynchrone Schnittstelle Xxx_GetScalingInformation wird über den Header Dcm_Externals.h bereitgestellt und dient dazu, Skalierungsinformationen eines Datenelements aus der Applikation anzufordern [SWS_Dcm_91012]. Das DCM-Modul ruft diese Funktion auf, sobald eine Diagnoseanfrage für den UDS-Dienst ReadScalingByIdentifier empfangen wird, und zwar für jedes Datum, das für die angefragte DID konfiguriert ist [SWS_Dcm_00394].

Parameter und Rückgabewerte

Die Funktion definiert folgende Parameter und Semantik [SWS_Dcm_91012]:

• OpStatus (in): Übergibt den aktuellen Status der laufenden Operation.
• ScalingInfo (out): Puffer zur Aufnahme der Skalierungsinformationen (scalingByte und scalingByteExtension).
• ErrorCode (out): Nimmt den negativen Antwortcode auf, falls die Operation fehlschlägt.

Als Rückgabewerte sind E_OK bei erfolgreichem Abschluss, E_NOT_OK bei einem Fehler sowie DCM_E_PENDING spezifiziert, falls die Bearbeitung noch nicht abgeschlossen ist und weitere Aufrufe zur Fertigstellung benötigt [SWS_Dcm_91012].

Fehlerbehandlung und Nebenläufigkeit

Gibt der Aufruf E_NOT_OK zurück, muss das DCM-Modul eine negative Antwort versenden, deren NRC dem über den Ausgabeparameter ErrorCode bereitgestellten Wert entspricht [SWS_Dcm_91012]. Die Funktion ist als nicht reentrant (Non Reentrant) spezifiziert [SWS_Dcm_91012]. Interpretation: Ob diese asynchrone Funktion mit OpStatus oder die alternativ spezifizierte synchrone Variante ohne OpStatus [SWS_Dcm_00798] aufgerufen wird, dürfte von der Konfiguration der jeweiligen DID abhängen. Frage Q-c4054a798f17a52c (offen)

Die Funktion Xxx_ReturnControlToECU wird über den Header Dcm_Externals.h bereitgestellt und fordert die Applikation auf, die Kontrolle über eine Ein-/Ausgabesteuerung (IOControl) an das Steuergerät zurückzugeben [SWS_Dcm_01285]. Der Aufruf erfolgt synchron und ist als nicht reentrant spezifiziert [SWS_Dcm_01285].

Parameter und Varianten

Die Funktionssignatur hängt von der Konfiguration der externen Steuermaske ab [SWS_Dcm_01285]:

• Ist DcmDspDidControlMask auf DCM_CONTROLMASK_EXTERNAL gesetzt und beträgt die Maskengröße bis zu vier Byte (DcmDspDidControlMaskSize <= 0x04), wird der Eingabeparameter controlMask vom Typ Dcm_ControlMask_{DID}Type übergeben [SWS_Dcm_01285].
• Beträgt die Maskengröße fünf oder mehr Byte (DcmDspDidControlMaskSize >= 0x05), wird stattdessen der Zeiger controlMask2 vom Typ uint8* verwendet [SWS_Dcm_01285].
• Über den Ausgangsparameter ErrorCode (Typ Dcm_NegativeResponseCodeType*) übermittelt die Funktion im Fehlerfall den spezifischen negativen Antwortcode (NRC) an das DCM [SWS_Dcm_01285].

Rückgabewerte und Fehlerbehandlung

Die Funktion liefert den Status Std_ReturnType zurück. Bei erfolgreicher Rückgabe der Kontrolle meldet die Applikation E_OK [SWS_Dcm_01285]. Schlägt die Operation fehl, muss die Funktion E_NOT_OK zurückgeben; in diesem Fall sendet das DCM-Modul eine negative Antwort mit dem in ErrorCode hinterlegten NRC an den Diagnosetester [SWS_Dcm_01285].

Zusammenspiel und Aufrufkontext

Das DCM ruft die konfigurierte Funktionsschnittstelle (Parameter DcmDspDataReturnControlToEcuFnc) auf, wenn DcmDspDataUsePort auf USE_DATA_SYNCH_FNC, USE_DATA_ASYNCH_FNC oder USE_DATA_ASYNCH_FNC_ERROR konfiguriert ist [SWS_Dcm_01435]. Neben regulären Diagnoseaktionen wird Xxx_ReturnControlToECU vom DCM insbesondere aufgerufen, wenn eine aktive IO-Steuerungssequenz abgebrochen werden muss [SWS_Dcm_01435].

Die synchrone Funktionsschnittstelle Xxx_ResetToDefault wird über den Header Dcm_Externals.h bereitgestellt und dient dazu, eine Applikation zum Zurücksetzen einer I/O-Steuerung (IOControl) auf den Standardwert aufzufordern [SWS_Dcm_01286].

Aufrufkontext und Parameter

Die Funktion besitzt die Service-ID 0x4d, arbeitet synchron und ist als nicht reentrant spezifiziert [SWS_Dcm_01286]. In Abhängigkeit von der konfigurierten Größe der externen Steuermaske wird einer von zwei alternativen Eingangsparametern übergeben:

• controlMask (Typ Dcm_ControlMask_{DID}Type) kommt zum Einsatz, wenn DcmDspDataUsePort auf USE_DATA_SYNCH_FNC konfiguriert ist, DcmDspDidControlMask auf DCM_CONTROLMASK_EXTERNAL steht und DcmDspDidControlMaskSize höchstens 0x04 beträgt [SWS_Dcm_01286].
• controlMask2 (Typ uint8*) wird verwendet, wenn unter identischen Randbedingungen DcmDspDidControlMaskSize größer oder gleich 0x05 konfiguriert ist [SWS_Dcm_01286].

Rückgabewerte und Fehlerbehandlung

Konnte das Zurücksetzen erfolgreich durchgeführt werden, liefert die Funktion E_OK zurück [SWS_Dcm_01286]. Schlägt die Operation fehl, muss E_NOT_OK zurückgegeben werden. In diesem Fall belegt die Applikation den Ausgabeparameter ErrorCode (Typ Dcm_NegativeResponseCodeType*) mit dem entsprechenden negativen Antwortcode (NRC), welchen das DCM-Modul als negative Rückmeldung an den Tester übermittelt [SWS_Dcm_01286].

Zusammenspiel und Abgrenzung

Ist das System für asynchrone Schnittstellenabwicklungen über USE_DATA_ASYNCH_FNC oder USE_DATA_ASYNCH_FNC_ERROR ausgelegt, kommt anstelle dieser synchronen Funktion die asynchrone Variante mit dem zusätzlichen Parameter OpStatus und der Service-ID 0x3c zum Einsatz [SWS_Dcm_01314].

Die asynchrone Funktion [SWS_Dcm_01314] fordert die Applikation auf, eine Ein-/Ausgabesteuerung (IOControl) auf ihren Standardwert zurückzusetzen. Sie ist in Dcm_Externals.h deklariert und besitzt die Service-ID 0x3c. Über den Parameter OpStatus wird der Fortschritt der Operation gesteuert. Bei noch nicht abgeschlossener Verarbeitung liefert die Funktion DCM_E_PENDING zurück, während ein erfolgreicher Abschluss mit E_OK bestätigt wird.

Abhängig von der Konfiguration und der Maskengröße (DcmDspDidControlMaskSize bis 4 Byte oder ab 5 Byte) wird bei externer Maskierung zusätzlich controlMask bzw. controlMask2 übergeben [SWS_Dcm_01314]. Schlägt die Rücksetzung fehl, gibt die Funktion E_NOT_OK zurück. In diesem Fall muss über den Ausgabeparameter ErrorCode ein negativer Antwortcode (NRC) übergeben werden, den das DCM-Modul als negative Response an den Tester sendet [SWS_Dcm_01314].

Die Funktion ist nicht reentrant (Non Reentrant) spezifiziert [SWS_Dcm_01314]. Sie kommt zum Einsatz, wenn DcmDspDataUsePort auf USE_DATA_ASYNCH_FNC oder USE_DATA_ASYNCH_FNC_ERROR gesetzt ist. Für synchrone Schnittstellenkonfigurationen (USE_DATA_SYNCH_FNC) existiert alternativ die synchrone Variante ohne OpStatus [SWS_Dcm_01286].

Verwendung

Die synchrone Funktion Xxx_FreezeCurrentState (im Elementkatalog als Xxx_FreezeCurrentStateManager geführt) dient dazu, eine Applikation zum Einfrieren des aktuellen Zustands einer Ein- oder Ausgabesteuerung (IOControl) aufzufordern [SWS_Dcm_01290]. Die Funktion ist über die Header-Datei Dcm_Externals.h verfügbar und besitzt die Service-ID 0x4a AUTOSAR_SWS_DiagnosticCommunicationManager S. 279. (Interpretation: Das Präfix Xxx dürfte dabei als Platzhalter für das jeweilige Anwendungsmodul stehen.) Frage Q-f8c864cda732acc2 (offen)

Die Schnittstellenparameter richten sich nach der Konfiguration der externen Steuermaske (DcmDspDidControlMask auf DCM_CONTROLMASK_EXTERNAL) [SWS_Dcm_01290]:

• controlMask (Eingabe, Typ Dcm_ControlMask_{DID}Type): Wird übergeben, wenn die Maskengröße DcmDspDidControlMaskSize kleiner oder gleich 4 Byte (<= 0x04) konfiguriert ist.
• controlMask2 (Eingabe, Typ uint8*): Kommt stattdessen zum Einsatz, wenn die Maskengröße mindestens 5 Byte (=> 0x05) umfasst.
• ErrorCode (Ausgabe, Typ Dcm_NegativeResponseCodeType*): Zeiger zur Aufnahme eines negativen Antwortcodes bei Fehlern.

Fehlerbehandlung und Rückgabewerte

Die Funktion liefert als Std_ReturnType entweder E_OK bei erfolgreicher Ausführung oder E_NOT_OK, wenn die Anforderung nicht erfolgreich war [SWS_Dcm_01290]. Tritt ein Fehler auf und wird E_NOT_OK zurückgegeben, muss die Applikation im Parameter ErrorCode einen spezifischen negativen Antwortcode (NRC) eintragen; das DCM-Modul sendet daraufhin eine negative Diagnoseantwort mit diesem NRC-Code AUTOSAR_SWS_DiagnosticCommunicationManager S. 279.

Nebenläufigkeit und Einschränkungen

Die Operation ist als nicht-reentrant (Non Reentrant) spezifiziert [SWS_Dcm_01290]. Aufrufer müssen sicherstellen, dass Aufrufe für dieselbe Instanz synchron und ohne gleichzeitige Überlappung abgearbeitet werden.

Verwendung und Aufrufkontext

Die asynchrone Funktion Xxx_FreezeCurrentState wird vom DCM-Modul aufgerufen, um bei der Anwendungssoftware das Einfrieren des aktuellen Zustands einer Ein-/Ausgabesteuerung (IOControl) anzufordern [SWS_Dcm_01315]. Die Deklaration wird über den Header Dcm_Externals.h bereitgestellt [SWS_Dcm_01315].

Parameter und Steuermasken

Der Aufruf erfolgt mit folgenden Parametern [SWS_Dcm_01315]:

• OpStatus: Übermittelt den aktuellen Status der asynchronen Operation (Dcm_OpStatusType).
• controlMask bzw. controlMask2: Wenn die Steuermaske extern konfiguriert ist (DcmDspDidControlMask == DCM_CONTROLMASK_EXTERNAL) und die asynchrone Funktionsschnittstelle genutzt wird, übergibt das DCM abhängig von DcmDspDidControlMaskSize bei bis zu 4 Bytes den Parameter controlMask (vom Typ Dcm_ControlMask_{DID}Type) und ab 5 Bytes den Zeiger controlMask2 (uint8*).
• ErrorCode: Zeiger auf Dcm_NegativeResponseCodeType zur Rückgabe eines Fehlercodes.

Rückgabewerte und Fehlerbehandlung

Die Funktion liefert einen Status vom Typ Std_ReturnType zurück [SWS_Dcm_01315]:

• E_OK: Das Einfrieren des Zustands wurde erfolgreich abgeschlossen.
• DCM_E_PENDING: Die Anforderung ist noch in Bearbeitung und erfordert Folgebeschickungen.
• E_NOT_OK: Die Operation ist fehlgeschlagen. In diesem Fall sendet das DCM eine negative Diagnoseantwort mit dem über ErrorCode gesetzten NRC-Wert.

Nebenläufigkeit

Die Schnittstelle ist als nicht reentrant (Non Reentrant) definiert und bedarf daher einer synchronisierten Bearbeitung pro Steuerinstanz [SWS_Dcm_01315].

Die synchrone Funktion Xxx_ShortTermAdjustment fordert die Anwendung auf, ein bestimmtes I/O-Signal temporär anzupassen [SWS_Dcm_00802]. Sie wird über den Header Dcm_Externals.h bereitgestellt und besitzt die Service-ID 0x50 [SWS_Dcm_00802].

Über den Zeiger ControlStateInfo erhält die Funktion die Steuerzustandsinformationen aus dem Parameter ControlOptionRecord der Diagnoseanforderung InputOutputControlByIdentifier [SWS_Dcm_00802]. Ist eine externe Steuermaske konfiguriert (DcmDspDidControlMask == DCM_CONTROLMASK_EXTERNAL), wird abhängig von DcmDspDidControlMaskSize zusätzlich entweder controlMask (bis 4 Byte) vom Typ Dcm_ControlMask_{DID}Type oder controlMask2 (ab 5 Byte) als uint8* übergeben [SWS_Dcm_00802].

Als Rückgabewert liefert die Operation Std_ReturnType [SWS_Dcm_00802]:

• E_OK: Die Anpassung des I/O-Signals wurde erfolgreich ausgeführt [SWS_Dcm_00802].
• E_NOT_OK: Die Anpassung schlug fehl [SWS_Dcm_00802]. In diesem Fall muss die Anwendung über den Ausgabeparameter ErrorCode einen spezifischen negativen Antwortcode (Dcm_NegativeResponseCodeType) setzen, den das DCM-Modul in der negativen Diagnoseantwort an den Tester zurücksendet [SWS_Dcm_00802].

Die Funktion ist nicht reentrant (Non Reentrant) und wird synchron aufgerufen [SWS_Dcm_00802]. Diese synchrone Variante wird verwendet, wenn das Datenelement für synchrone Funktionsaufrufe konfiguriert ist (DcmDspDataUsePort == USE_DATA_SYNCH_FNC) [SWS_Dcm_00802]. Für asynchron konfigurierte Ports (USE_DATA_ASYNCH_FNC oder USE_DATA_ASYNCH_FNC_ERROR) existiert hingegen die asynchrone Variante mit Service-ID 0x55 und erweitertem Parametersatz einschließlich OpStatus und DataLength [SWS_Dcm_01316].

Verwendung und Aufrufkontext

Die Funktion [SWS_Dcm_01316] wird vom Diagnostic Communication Manager (DCM) aufgerufen und über Dcm_Externals.h bereitgestellt. Sie fordert die Applikation asynchron dazu auf, ein IO-Signal im Rahmen des Diagnosedienstes InputOutputControlByIdentifier anzupassen. Die Steuerdaten werden über den Zeiger ControlStateInfo (aus dem Parameter ControlOptionRecord) übergeben, ergänzt um die Bytelänge DataLength. Der Ablauf wird über OpStatus gesteuert: Solange die Anpassung andauert, gibt die Anwendung DCM_E_PENDING zurück; nach erfolgreichem Abschluss meldet sie E_OK.

Varianten und Maskenparameter

Bei externer Konfiguration der Kontrollmaske (DCM_CONTROLMASK_EXTERNAL) werden zusätzliche Parameter übergeben [SWS_Dcm_01316]:

• Ist die Maskengröße kleiner oder gleich 4 Byte, wird controlMask vom Typ Dcm_ControlMask_{DID}Type übergeben.
• Beträgt die Maskengröße mindestens 5 Byte, wird stattdessen controlMask2 als Zeiger auf uint8 übergeben.

Fehlerbehandlung und Nebenläufigkeit

Schlägt die Signalsteuerung fehl, liefert die Funktion E_NOT_OK zurück und setzt über den Zeiger ErrorCode den negativen Antwortcode (NRC), welchen der DCM in der negativen Antwort übermittelt [SWS_Dcm_01316]. Die Funktion ist als nicht-reentrant spezifiziert.

Zusammenspiel und Abgrenzung

Die Schnittstelle wird genutzt, wenn der DID-Datenport auf USE_DATA_ASYNCH_FNC oder USE_DATA_ASYNCH_FNC_ERROR und der Datentyp auf UINT8_DYN konfiguriert ist [SWS_Dcm_01316]. Sie unterscheidet sich von der synchronen Variante [SWS_Dcm_00802], welche weder OpStatus noch DataLength verwendet und für synchrone Ports bei statischen Datentypen bestimmt ist.

Die Funktion Xxx_IsDidAvailable dient zur asynchronen Prüfung, ob ein angeforderter Diagnostic Identifier (DID) innerhalb eines definierten DID-Bereichs verfügbar ist [SWS_Dcm_00803]. Sie wird über den Header Dcm_Externals.h bereitgestellt und besitzt die Service-ID 0x53 [SWS_Dcm_00803].

Verwendung und Parameter

Der Aufruf erfolgt mit folgenden Parametern [SWS_Dcm_00803]:

• DID (In): Der abzufragende Kennungswert des DID [SWS_Dcm_00803].
• OpStatus (In): Der aktuelle Status der Operation zur Steuerung des asynchronen Ablaufs [SWS_Dcm_00803].
• supported (Out): Zeigt an, ob der DID im Bereich verfügbar ist; DCM_DID_SUPPORTED bedeutet Unterstützung, während DCM_DID_NOT_SUPPORTED die Nichtunterstützung anzeigt [SWS_Dcm_00803].

Asynchrone Semantik und Rückgabewerte

Da die Funktion asynchron ausgeführt wird, erfordert die Ermittlung unter Umständen mehrere Aufrufschritte [SWS_Dcm_00803]. Der Rückgabewert DCM_E_PENDING signalisiert, dass die Anfrage noch nicht abgeschlossen ist und weitere Aufrufe zur Fertigstellung nötig sind [SWS_Dcm_00803]. Der Rückgabewert E_OK wird gemeldet, wenn die Prüfung abgeschlossen ist [SWS_Dcm_00803] (Interpretation: Vermutlich schließt E_OK die Abfrage ab, woraufhin der Parameter supported das gültige Ergebnis enthält). Frage Q-22c62d306a7ac4f1 (offen)

Nebenläufigkeit und Einschränkungen

Die Schnittstelle ist als nicht reentrant (Non Reentrant) spezifiziert [SWS_Dcm_00803]. Parallele Aufrufe für denselben oder andere DIDs innerhalb derselben Instanz sind daher unzulässig.

Verwendung und Parameterschnittstelle

Die Funktion Xxx_ReadDidData (Service-ID 0x40) ist über Dcm_Externals.h verfügbar und fordert von der Applikation die Datenwerte eines Diagnose-Identifikators (DID) an [SWS_Dcm_00804]. Die Übergabe und Rückmeldung erfolgt über folgende Parameter:

• DID: Kennung des angeforderten Data Identifiers [SWS_Dcm_00804].
• Data: Zeiger auf den Puffer, in den die gelesenen Nutzdaten kopiert werden müssen [SWS_Dcm_00804].
• OpStatus: Fortschritts- bzw. Operationsstatus der aktuellen Anforderung [SWS_Dcm_00804].
• DataLength: Länge der zu lesenden Daten [SWS_Dcm_00804].
• ErrorCode: Ausgabeparameter zur Aufnahme eines negativen Antwortcodes (NRC) [SWS_Dcm_00804].

Asynchrone Semantik und Rückgabewerte

Die Funktion ist als asynchron (Asynchronous) definiert und liefert einen Status vom Typ Std_ReturnType zurück [SWS_Dcm_00804]:

• E_OK: Das Auslesen der Daten war erfolgreich [SWS_Dcm_00804].
• DCM_E_PENDING: Die Anfrage ist noch nicht abgeschlossen; zur Fertigstellung sind weitere Aufrufe erforderlich [SWS_Dcm_00804].
• E_NOT_OK: Die Operation war nicht erfolgreich [SWS_Dcm_00804].

Fehlerbehandlung und Nebenläufigkeit

Liefert die Applikation für Xxx_ReadDidData den Rückgabewert E_NOT_OK, sendet das DCM-Modul eine negative Antwort mit dem über den Parameter ErrorCode gesetzten NRC-Code an den Diagnosetester [SWS_Dcm_00804]. Die Funktion ist als nicht reentrant (Non Reentrant) spezifiziert [SWS_Dcm_00804]. Interpretation: Aufgrund der asynchronen Abwicklung mit DCM_E_PENDING dürfte der Aufruf typischerweise im zyklischen Task-Kontext des DCM erfolgen. Frage Q-5e41e9fb7dc261b9 (offen)

Die Funktion Xxx_WriteDidData wird vom Modul DCM aufgerufen, um die Applikation zum Schreiben des Datenwerts eines DID aufzufordern [SWS_Dcm_00805]. Die Deklaration ist über den Header Dcm_Externals.h verfügbar [SWS_Dcm_00805].

Aufruf und Semantik

Der Aufruf erfolgt asynchron und ist als nicht reentrant (Non Reentrant) definiert [SWS_Dcm_00805]. Beim Aufruf werden folgende Parameter übergeben [SWS_Dcm_00805]:

• DID: Kennung des zu schreibenden Datenbezeichners.
• Data: Zeiger auf den Puffer mit den zu schreibenden Daten.
• OpStatus: Status der aktuellen Operation.
• DataLength: Länge der zu schreibenden Daten in Bytes.
• ErrorCode: Ausgabeparameter für den negativen Antwortcode (NRC).

Rückgabewerte und Fehlerbehandlung

Als Rückgabewert liefert die Funktion Std_ReturnType mit folgenden Bedeutungen [SWS_Dcm_00805]:

• E_OK: Der Schreibauftrag wurde erfolgreich ausgeführt.
• DCM_E_PENDING: Die Operation ist noch nicht abgeschlossen; zur Fertigstellung sind weitere Aufrufe erforderlich.
• E_NOT_OK: Die Operation war nicht erfolgreich. In diesem Fall sendet das DCM-Modul eine negative Antwort mit dem im Ausgabeparameter ErrorCode übergebenen NRC-Wert.

Die Funktion Xxx_ReadDidRangeDataLength dient dazu, die Anwendungssoftware zur Rückgabe der Datenlänge für einen DID-Bereich (DID Range) aufzufordern [SWS_Dcm_01271]. Sie ist Bestandteil des AUTOSAR-Moduls Dcm, besitzt die Service-ID 0x5e und wird über die Header-Datei Dcm_Externals.h zur Verfügung gestellt [SWS_Dcm_01271].

Der Aufruf erfolgt mit asynchroner Semantik (Asynchronous) über die folgenden Schnittstellenparameter [SWS_Dcm_01271]:

• DID (IN, uint16): Kennzeichnet den konkreten Daten-Identifier (Data ID value) des angefragten DID-Bereichs [SWS_Dcm_01271].
• OpStatus (IN, Dcm_OpStatusType): Gibt den aktuellen Verarbeitungsstatus der laufenden Operation an [SWS_Dcm_01271].
• DataLength (OUT, uint16*): Zeiger auf die Länge der Daten, die gelesen oder geschrieben werden sollen [SWS_Dcm_01271].

Der Rückgabewert vom Typ Std_ReturnType signalisiert das Ergebnis der Längenabfrage [SWS_Dcm_01271]:

• E_OK: Die Anfrage war erfolgreich und die ermittelte Länge liegt bereit [SWS_Dcm_01271].
• E_NOT_OK: Die Anfrage war nicht erfolgreich [SWS_Dcm_01271].
• DCM_E_PENDING: Die Ausführung ist noch nicht abgeschlossen und erfordert weitere Folgeaufrufe zur Fertigstellung [SWS_Dcm_01271].

Bezüglich der Nebenläufigkeit ist die Schnittstelle als nicht reentrant (Non Reentrant) festgelegt [SWS_Dcm_01271].

Die asynchrone Schnittstelle Xxx_GetInfotypeValueData wird vom DCM-Modul aufgerufen, sobald eine Diagnoseanfrage für den OBD Service $09 empfangen wird und der angeforderte InfoType kein Verfügbarkeits-InfoType („availability InfoType“) ist [SWS_Dcm_00423]. Um die Daten bereitzustellen, ruft das DCM alle für diesen InfoType konfigurierten Funktionen auf und führt die Werte als Antwort auf Service $09 zusammen [SWS_Dcm_00423]. Die Deklaration ist über Dcm_Externals.h verfügbar [SWS_Dcm_91014].

Die Übergabe und Rückmeldung der Daten erfolgt über definierte Puffer- und Statusparameter [SWS_Dcm_91014]:

• OpStatus (in): Zeigt den aktuellen Fortschrittsstatus der laufenden Operation an.
• DataValueBuffer (out): Puffer zur Aufnahme der spezifischen InfoType-Nutzdaten.
• DataValueBufferSize (inout): Enthält beim Aufruf die maximal beschreibbare Puffergröße in Byte und wird von der aufgerufenen Funktion mit der tatsächlichen Anzahl geschriebener Datenbytes belegt.

Als asynchrone Funktion liefert sie E_OK bei erfolgreichem Abschluss, E_NOT_OK bei Fehlern oder DCM_E_PENDING, falls die Operation noch nicht abgeschlossen ist und weitere Aufrufe zur Fertigstellung benötigt [SWS_Dcm_91014]. Da die Funktion als nicht reentrant (Non Reentrant) spezifiziert ist, dürfen keine nebenläufigen Aufrufe für dieselbe Funktion erfolgen [SWS_Dcm_91014].

Die Funktion Xxx_Start wird über die Header-Datei Dcm_Externals.h deklariert und fordert die Anwendungssoftware auf, die Ausführung einer Diagnose-Routine zu starten [SWS_Dcm_01203]. Das Modul DCM ruft diese Funktion auf, sobald eine UDS-Dienstanforderung für RoutineControl (0x31) mit der Unterfunktion startRoutine empfangen und erfolgreich verifiziert wurde [SWS_Dcm_00400], oder wenn eine RoutineControl-Anforderung mit einer Nicht-Verfügbarkeits-OBDTestId eingeht [SWS_Dcm_01392].

Die Schnittstelle unterstützt feste sowie variable Datenformate und wird asynchron betrieben [SWS_Dcm_01203]:

• Eingabeparameter: Feste Eingabesignale dataIn_1 bis dataIn_n oder variable Daten über das Bytefeld dataInVar sowie der Operationsstatus OpStatus [SWS_Dcm_01203].
• Ausgabeparameter: Feste Ausgangssignale dataOut_1 bis dataOut_n oder variable Ausgangsdaten dataOutVar sowie der Fehlercode ErrorCode für negative Antwortmeldungen [SWS_Dcm_01203].
• Längenparameter: Der Ein- und Ausgabeparameter currentDataLength transportiert bei variabler Datenlänge die Anzahl der Nutzbytes in dataInVar bzw. dataOutVar [SWS_Dcm_01203].
• Rückgabewerte: E_OK bestätigt den erfolgreichen Start, E_NOT_OK meldet einen Fehlschlag, DCM_E_PENDING signalisiert noch andauernde Bearbeitungsschritte und DCM_E_FORCE_RCRRP fordert das vorzeitige Senden einer Pending-Rückmeldung (NRC 0x78) an [SWS_Dcm_01203].

Bezüglich der Nebenläufigkeit ist Xxx_Start als nicht reentrant (Non Reentrant) definiert [SWS_Dcm_01203]. Bei asynchronen Abläufen mit dem Rückgabewert DCM_E_PENDING ruft das DCM-Modul die Funktion zyklisch mit fortgeführtem OpStatus erneut auf, bis der Vorgang abgeschlossen ist [SWS_Dcm_01203].

Wird die Operation erfolgreich mit E_OK beendet, sendet das DCM-Modul eine positive UDS-Antwort mit den über dataOut bereitgestellten Daten als routineStatusRecord zurück [SWS_Dcm_00401]. Schlägt die Ausführung mit E_NOT_OK fehl, übermittelt das DCM eine negative Antwort mit dem im Parameter ErrorCode spezifizierten NRC [SWS_Dcm_01203]. Im Kontext von OBD-Routinen führt ein Rückgabewert ungleich E_OK zum Senden von NRC 0x22 [SWS_Dcm_01394].

Verwendung

Die Funktion Xxx_StartConfirmation zeigt gemäß [SWS_Dcm_91016] die Übertragung einer Antwort auf eine vorangegangene StartRoutine-Anforderung verbindlich an. Die Schnittstelle ist in der Header-Datei Dcm_Externals.h deklariert und besitzt eine synchrone Ausführungssemantik ([SWS_Dcm_91016]). Als einziger Eingangsparameter wird ConfirmationStatus vom Typ Dcm_ConfirmationStatusType übergeben, der den Bestätigungsstatus der Routineübertragung beschreibt. Zusätzliche Ein- und Ausgabeparameter existieren laut Spezifikation nicht ([SWS_Dcm_91016]).

Fehlerbehandlung und Rückgabewerte

Als Rückgabewert liefert die Funktion einen Statuswert vom Typ Std_ReturnType ([SWS_Dcm_91016]). Dabei bestätigt der Wert E_OK die erfolgreiche Durchführung der Anforderung, wohingegen E_NOT_OK eine nicht erfolgreiche Verarbeitung signalisiert. Spezifische Fehlercodes oder explizite Meldungen an das Development Error Tracer (DET) oder Diagnostic Event Manager (DEM) sind für diese Funktion im Payload nicht definiert.

Nebenläufigkeit und Einschränkungen

Hinsichtlich der Nebenläufigkeit ist Xxx_StartConfirmation als nicht reentrant (Non Reentrant) klassifiziert ([SWS_Dcm_91016]). Dies erfordert vom Aufrufer, dass konkurrierende oder überlappende Ausführungen strikt vermieden werden. Interpretation: Die Funktion dürfte vom DCM aufgerufen werden, um die anwendungsseitige Routine-Implementierung über den Abschluss des Sendevorgangs zu benachrichtigen. Frage Q-be2dafd63bf2a9a5 (offen)

Verwendung

Die Funktion [SWS_Dcm_01204] wird vom DCM aufgerufen, um die Ausführung einer laufenden Diagnose-Routine in der Applikation zu beenden. Der Aufruf erfolgt im Rahmen des UDS-Dienstes RoutineControl (0x31) mit der Subfunktion stopRoutine, sobald die erforderlichen Vorprüfungen erfolgreich abgeschlossen sind [SWS_Dcm_00402]. Die Schnittstelle besitzt die Service-ID 0x5c und ist über die Header-Datei Dcm_Externals.h deklariert [SWS_Dcm_01204].

Parameter und Rückgabewerte

Abhängig von der Konfiguration der Routine übergibt das DCM feste oder variable Eingabedaten (dataIn_1 bis dataIn_n bzw. dataInVar) und Pufferreferenzen für Ausgabedaten (dataOut_1 bis dataOut_n bzw. dataOutVar) [SWS_Dcm_01204], [SWS_Dcm_00402]. Bei variabler Datenlänge enthält currentDataLength die Byteanzahl der Ein- bzw. Ausgabedaten [SWS_Dcm_01204]. Als Rückgabewerte von Std_ReturnType sind festgelegt:

• E_OK: Routine erfolgreich beendet; das DCM übermittelt eine positive UDS-Antwort mit den erzeugten Ausgabedaten als routineStatusRecord [SWS_Dcm_01204], [SWS_Dcm_00403].
• E_NOT_OK: Abbruch der Routine fehlgeschlagen; das DCM sendet eine negative UDS-Antwort mit dem in ErrorCode hinterlegten NRC [SWS_Dcm_01204].
• DCM_E_PENDING: Operation ist noch in Bearbeitung; das DCM ruft die Funktion zur Fertigstellung erneut auf [SWS_Dcm_01204].
• DCM_E_FORCE_RCRRP: Die Applikation fordert das DCM zur Übertragung einer Pending-Antwort (NRC 0x78) auf [SWS_Dcm_01204].

Nebenläufigkeit und Einschränkungen

Die Operation ist als asynchron und nicht reentrant (Non Reentrant) spezifiziert [SWS_Dcm_01204]. Tritt bei der Ausführung ein Fehler auf, muss die Applikation den Parameter ErrorCode mit dem passenden Dcm_NegativeResponseCodeType beschreiben und E_NOT_OK zurückgeben [SWS_Dcm_01204].

Die synchrone Funktion Xxx_StopConfirmation dient dazu, die Übertragung einer Antwort auf eine vorherige StopRoutine-Anforderung anzuzeigen [SWS_Dcm_91017]. Beim Aufruf übergibt das System über den Eingabeparameter ConfirmationStatus vom Typ Dcm_ConfirmationStatusType den konkreten Bestätigungsstatus der Routine-Beendigung [SWS_Dcm_91017]. Als Rückgabewert liefert die Schnittstelle einen Wert vom Typ Std_ReturnType: Hierbei zeigt E_OK an, dass die Anforderung erfolgreich bearbeitet wurde, während E_NOT_OK eine nicht erfolgreiche Anforderung signalisiert [SWS_Dcm_91017].

In Bezug auf Nebenläufigkeit und Aufrufbedingungen ist die Schnittstelle als nicht reentrant (Non Reentrant) spezifiziert und besitzt die Service-ID 0x69 [SWS_Dcm_91017]. Die Deklaration wird über die Header-Datei Dcm_Externals.h zur Verfügung gestellt [SWS_Dcm_91017]. Interpretation: Aufgrund der Bereitstellung über Dcm_Externals.h und des anpassbaren Präfixes Xxx_ dürfte die Funktion vom DCM-Modul aufgerufen und durch eine anwendungsspezifische Software-Komponente bzw. den zuständigen Routinen-Handler implementiert werden. Frage Q-743e69ff8cf92321 (offen)

Spezifische Fehlercodes oder Benachrichtigungen an das Entwicklungsfehler-Management (DET) oder Diagnostic Event Manager (DEM) sind in den Anforderungen nicht ausgewiesen. Das Verhalten im Fehlerfall beschränkt sich auf dieser Schnittstellenebene formal auf die Rückgabe des Fehlerwerts E_NOT_OK, wenn die Verarbeitung nicht erfolgreich abgeschlossen werden konnte [SWS_Dcm_91017].

Die Funktion [SWS_Dcm_91013] wird vom DCM-Modul aufgerufen, um von der Applikation das Ergebnis einer Routineausführung abzufragen. Dies geschieht im Rahmen des UDS-Dienstes RoutineControl (0x31) mit der Subfunktion requestRoutineResults, sobald alle eingangsseitigen Prüfungen erfolgreich durchlaufen wurden [SWS_Dcm_00404]. Die Schnittstelle ist über Dcm_Externals.h verfügbar, arbeitet asynchron und ist als nicht reentrant spezifiziert [SWS_Dcm_91013].

Über den Parameter OpStatus steuert das DCM-Modul den Ablauf der Operation. Die Funktion nimmt feste Eingabedaten (dataIn_1 bis dataIn_n) oder variable Daten (dataInVar) entgegen, die aus dem routineControlOptionRecord abgeleitet werden [SWS_Dcm_00404]. Über feste Ausgabeparameter (dataOut_1 bis dataOut_n) oder variable Ausgabepuffer (dataOutVar und variableDataLength) übergibt die Applikation die Ergebnisdaten an den DCM [SWS_Dcm_91013].

Wird die Abfrage erfolgreich mit E_OK abgeschlossen, führt das DCM-Modul die Ausgabedaten anhand des Konfigurationsparameters DcmDspRequestRoutineResultsOut zu einem routineStatusRecord zusammen und versendet eine positive Antwort [SWS_Dcm_00405]. Falls die Operation noch andauert, kann die Applikation DCM_E_PENDING für Folgeaufrufe oder DCM_E_FORCE_RCRRP zum Senden einer vorläufigen Antwort (NRC 0x78) zurückgeben [SWS_Dcm_91013].

Im Fehlerfall liefert die Funktion E_NOT_OK zurück und setzt ErrorCode auf den zutreffenden NRC-Wert, woraufhin das DCM-Modul eine entsprechende negative Antwort übermittelt [SWS_Dcm_91013]. Da die Funktion nicht reentrant ist, darf sie für dieselbe Routine nicht parallel aufgerufen werden [SWS_Dcm_91013].

Verwendung und Semantik

Die Funktion Xxx_RequestResultsConfirmation dient der Bestätigung einer übertragenen Diagnoseantwort auf eine RequestRoutineResults-Anforderung [SWS_Dcm_91018]. Sie ist in der Header-Datei Dcm_Externals.h deklariert und besitzt die Service-ID 0x70 [SWS_Dcm_91018]. Über den Eingangsparameter ConfirmationStatus vom Typ Dcm_ConfirmationStatusType erhält die Implementierung Information darüber, mit welchem Status die Übertragung der Routine-Ergebnisse abgeschlossen wurde [SWS_Dcm_91018]. Der Aufruf wird synchron ausgeführt und gibt einen Std_ReturnType zurück, wobei E_OK eine erfolgreiche Bearbeitung anzeigt und E_NOT_OK ein Fehlschlagen signalisiert [SWS_Dcm_91018].

Nebenläufigkeit und Einschränkungen

Gemäß Spezifikation ist die Funktion als nicht reentrant (Non Reentrant) eingestuft [SWS_Dcm_91018]. Daher dürfen gleichzeitige Aufrufe für dieselbe Instanz nicht stattfinden. Interpretation: Der Aufruf durch das DCM-Modul erfolgt sequenziell im Kontext der Antwortbestätigung, weshalb die Funktion ohne blockierende Operationen ausgeführt werden sollte. Frage Q-935a06744e7b9af7 (offen)

Fehlerbehandlung und Zusammenspiel

Die Fehlerbehandlung beschränkt sich auf den Rückgabewert E_NOT_OK, da gesonderte Entwicklungsfehler (DET) oder Produktionsfehler (DEM) für diesen Aufruf nicht spezifiziert sind [SWS_Dcm_91018]. Interpretation: Die Funktion dient als anwendungsspezifischer Bestätigungsendpunkt (Callback) für das DCM, um nach dem Versand der Routinenergebnisse den Abschluss des Diagnoseauftrags auf Anwenderebene zu synchronisieren. Frage Q-d3dd0142a30e1363 (offen)

Die Funktion Xxx_RequestControl dient der Ausführung einer TID-spezifischen Steuerfunktion und wird typischerweise zur Implementierung von OBD Service $08 eingesetzt ([SWS_Dcm_01338]). Das DCM-Modul ruft die konfigurierte Funktion synchron auf, sobald eine OBD-Service-$08-Anfrage empfangen wird, deren Test-ID (TID) keine Verfügbarkeits-TID („availability TID“) darstellt ([SWS_Dcm_00419]). Die Deklaration der Schnittstelle wird über die Header-Datei Dcm_Externals.h bereitgestellt ([SWS_Dcm_01338]).

Parameter und Pufferhandhabung

• InBuffer: Zeiger auf die Nutzdaten der empfangenen OBD-Anforderung. Die Bytezahl dieser Eingabedaten muss exakt der im DCM-Modul konfigurierten Größe entsprechen ([SWS_Dcm_00419], [SWS_Dcm_01338]).
• OutBuffer: Zeiger auf den Ausgabepuffer, in dem die aufgerufene Steuerfunktion ihre Ergebnisse ablegt. Die Puffergröße ist fest vorgegeben und wird der Konfiguration des DCM-Moduls entnommen ([SWS_Dcm_00419], [SWS_Dcm_01338]).

Rückgabewerte und Fehlerbehandlung

Die Funktion liefert als Statuswert Std_ReturnType zurück: Der Wert E_OK signalisiert eine erfolgreiche Abarbeitung, während E_NOT_OK einen Fehlerzustand anzeigt ([SWS_Dcm_01338]). Liefert Xxx_RequestControl ein anderes Ergebnis als E_OK zurück, reagiert das DCM-Modul mit dem negativen Antwortcode NRC 0x22 (Conditions Not Correct) gegenüber dem Diagnose-Tester ([SWS_Dcm_01192]).

Nebenläufigkeit und Einschränkungen

Die Funktion ist als nicht reentrant (Non Reentrant) spezifiziert und besitzt die Service-ID 0x63 ([SWS_Dcm_01338]).

Die Callback-Funktion Xxx_StartProtocol wird über den Header Dcm_Externals.h bereitgestellt und ermöglicht der Applikation, bei der ersten Anfrage eines Diagnoseprotokolls aktuelle Umgebungsbedingungen zu prüfen und die weitere Protokollverarbeitung freizugeben oder abzulehnen [SWS_Dcm_01339].

Aufrufkontext und Parameter

Der Aufruf erfolgt durch das DSL-Submodul des DCM synchron und nicht-reentrant für alle konfigurierten Funktionen [SWS_Dcm_00036], [SWS_Dcm_01339]. An die Funktion werden folgende Eingangsparameter übergeben [SWS_Dcm_01339]:

• ProtocolType: Typ des zu startenden Diagnoseprotokolls,
• TesterSourceAddress: Quelladresse des anfragenden Testers,
• ConnectionId: Eindeutige Kennung der Verbindung.

Rückgabewerte und Fehlerbehandlung

Als Rückgabewert liefert die Funktion Std_ReturnType mit E_OK bei erfolgreicher Freigabe, E_NOT_OK bei nicht erfolgreicher Prüfung oder E_PROTOCOL_NOT_ALLOWED, falls das Protokoll unzulässig ist [SWS_Dcm_01339]. Gibt mindestens eine konfigurierte Xxx_StartProtocol-Funktion nicht E_OK zurück, bricht das DCM den Protokollstart ab und antwortet mit NRC 0x22 [SWS_Dcm_00674].

Initialisierung nach erfolgreicher Freigabe

Erst wenn alle konfigurierten Xxx_StartProtocol-Callbacks E_OK zurückgegeben haben, führt das DCM die weiteren Initialisierungsschritte aus:

• Laden der Standard-Timing-Parameter aus der Default-Session-Konfiguration [SWS_Dcm_00144],
• Aktivieren der Diensttabelle [SWS_Dcm_00145],
• Zurücksetzen des Sicherheitsstatus (Security State) [SWS_Dcm_00146],
• Rücksetzen des Sitzungsstatus auf die Standard-Diagnosesitzung sowie Ausführen des Moduswechsels über SchM_Switch_<bsnp>_DcmDiagnosticSessionControl auf RTE_MODE_DcmDiagnosticSessionControl_DEFAULT_SESSION [SWS_Dcm_00147].

Die synchrone Callback-Funktion Xxx_StopProtocol informiert die Anwendung über das Beenden eines Diagnoseprotokolls ([SWS_Dcm_01340]). Sie wird über die Header-Datei Dcm_Externals.h deklariert und ist als nicht reentrant (Non Reentrant) spezifiziert ([SWS_Dcm_01340]).

Der Aufruf aller konfigurierten Xxx_StopProtocol-Funktionen (konfiguriert über den Parameter DcmDslCallbackDCMRequestService) wird vom DSL-Submodul in folgenden Preemption-Szenarien ausgelöst:

• Eine laufende Diagnoseanforderung wird durch eine höher priorisierte Anforderung eines anderen Protokolls verdrängt ([SWS_Dcm_00459]).
• Eine Anforderung mit niedrigerer oder gleicher Priorität verdrängt ein höher priorisiertes Protokoll, sofern sich dieses in der Default Session befindet und keine aktive Anforderung in der Ausführungsphase ist ([SWS_Dcm_00625]).

Beim Aufruf werden der Protokolltyp (ProtocolType), die Tester-Quelladresse (TesterSourceAddress) sowie die Verbindungskennung (ConnectionId) übergeben ([SWS_Dcm_01340]). Als Rückgabewert liefert die Funktion E_OK bei erfolgreicher Durchführung oder E_NOT_OK ([SWS_Dcm_01340]). Liefert die Funktion nicht E_OK zurück, antwortet das DCM mit dem negativen Antwortcode NRC 0x22 ([SWS_Dcm_01190]).

Die synchrone, nicht-reentrante Funktion Xxx_Indication wird über den Header Dcm_Externals.h deklariert [SWS_Dcm_01341]. Sie zeigt der Applikation die bevorstehende Ausführung eines Diagnosedienstes an und ermöglicht es ihr, die Ausführung der Service-Anforderung abzulehnen [SWS_Dcm_01341]. Der Aufruf erfolgt synchron durch das DSD-Submodul an allen konfigurierten ServiceRequestIndication-Ports, wenn die Konfigurationscontainer DcmDsdServiceRequestManufacturerNotification [SWS_Dcm_00218] oder DcmDsdServiceRequestSupplierNotification [SWS_Dcm_00516] vorhanden sind.

Als Eingabeparameter werden die Service-ID (SID), die Anforderungsdaten ohne SID (RequestData, DataSize), der Adressierungstyp (ReqType), die Verbindungs-ID (ConnectionId), der Protokolltyp (ProtocolType) und die Quelladresse des Testers (TesterSourceAddress) übergeben [SWS_Dcm_01341].

Über den Rückgabewert vom Typ Std_ReturnType steuert die Applikation die Reaktion des DSD-Submoduls [SWS_Dcm_01341]:

• E_OK: Die Anforderung war erfolgreich und wird regulär weiterverarbeitet [SWS_Dcm_01341].
• E_REQUEST_NOT_ACCEPTED: Die Anforderung wird nicht akzeptiert. Gibt mindestens eine aufgerufene Indication-Funktion E_REQUEST_NOT_ACCEPTED zurück, unterdrückt das DSD-Submodul jegliche Antwort an den Tester [SWS_Dcm_00462], [SWS_Dcm_00517].
• E_NOT_OK: Die Anforderung war nicht erfolgreich. Die Applikation schreibt in diesem Fall einen negativen Antwortcode in den Ausgabeparameter ErrorCode [SWS_Dcm_01341]. Sofern kein Aufruf E_REQUEST_NOT_ACCEPTED zurückgibt, sendet das DSD-Submodul eine negative Antwort mit diesem NRC [SWS_Dcm_00463], [SWS_Dcm_00518].

Geben bei mehreren konfigurierten Benachrichtigungen mehrere Funktionen E_NOT_OK zurück und keine Funktion E_REQUEST_NOT_ACCEPTED, so verwendet das DSD-Submodul für die negative Antwort verbindlich den ErrorCode der ersten mit E_NOT_OK antwortenden Funktion [SWS_Dcm_01321], [SWS_Dcm_01322].

Die Callback-Funktion Xxx_Confirmation dient dazu, der Applikation den Abschluss einer Diagnoseübertragung – entweder die erfolgreiche Aussendung oder einen Übertragungsfehler – synchron mitzuteilen ([SWS_Dcm_01342]). Die Deklaration wird über den Header Dcm_Externals.h bereitgestellt ([SWS_Dcm_01342]).

Beim Aufruf durch das DCM-Submodul DSD (Diagnostic Service Dispatcher) werden wesentliche Kontextdaten des Diagnoseauftrags übergeben ([SWS_Dcm_01342], [SWS_Dcm_00741]):

• SID: Identifikator des Diagnosedienstes ([SWS_Dcm_01342]).
• ReqType: Adressierungsart (0 für physikalisch, 1 für funktional) ([SWS_Dcm_01342]).
• ConnectionId, ProtocolType und TesterSourceAddress: Eindeutige Verbindungs- und Protokollattribute sowie die Quelladresse des Testers ([SWS_Dcm_01342]).
• ConfirmationStatus: Statusinformation über Erfolg oder Fehler der Übertragung ([SWS_Dcm_01342]).

Als Rückgabewert liefert die Operation Std_ReturnType (E_OK bei erfolgreicher Bestätigungsverarbeitung, andernfalls E_NOT_OK) ([SWS_Dcm_01342]). Das DSD ruft die Funktion auf allen Ports auf, die das Interface ServiceRequestNotification nutzen (konfiguriert über DcmDsdServiceRequestManufacturerNotification bzw. DcmDsdServiceRequestSupplierNotification) ([SWS_Dcm_00741]).

Bezüglich der Aufrufreihenfolge wird Xxx_Confirmation regulär direkt im Anschluss an DspInternal_DcmConfirmation() ausgeführt ([SWS_Dcm_00742]). Liegt jedoch der Sonderfall nach [SWS_Dcm_01172] vor, ruft das DSD ausschließlich Xxx_Confirmation auf, während der interne Aufruf entfällt.

Da Xxx_Confirmation als nicht reentrant (Non Reentrant) und synchron spezifiziert ist ([SWS_Dcm_01342]), dürfte die anwendungsseitige Implementierung keine blockierenden Abläufe enthalten und keine reentranten Rückaufrufe in das DCM auslösen (Interpretation). Frage Q-58ce3e44dc61540b (offen)

Verwendung

Die synchrone Callout-Funktion Xxx_ClearDTCCheckFnc wird über die Header-Datei Dcm_Externals.h für die Applikation bereitgestellt [SWS_Dcm_01270]. Sie dient zur hersteller- und lieferantenspezifischen Überprüfung von Bedingungen vor dem Löschen einer angeforderten Gruppe von Diagnose-Fehlercodes (Group of DTC). Als Eingabeparameter wird ihr der Bezeichner GoDTC vom Typ uint32 übergeben, der die zu löschende Fehlercodegruppe spezifiziert [SWS_Dcm_01270].

Fehlerbehandlung und Rückgabewerte

Die Freigabe der Löschanforderung erfolgt über den Rückgabewert vom Typ Std_ReturnType im Zusammenspiel mit dem Ausgabeparameter ErrorCode [SWS_Dcm_01270]:

• E_OK: Die Applikation gestattet das Löschen der angeforderten Fehlercodegruppe GoDTC [SWS_Dcm_01270].
• E_NOT_OK: Die Applikation untersagt das Löschen der Gruppe. In diesem Fehlerfall muss über den Ausgabeparameter ErrorCode vom Typ Dcm_NegativeResponseCodeType* ein negativer Antwortcode gesetzt werden. Das Modul DCM versendet daraufhin eine negative Antwort mit dem in ErrorCode angegebenen NRC-Wert [SWS_Dcm_01270].

Nebenläufigkeit und Einschränkungen

Die Funktion ist mit der Service-ID 0x5f versehen, arbeitet synchron und ist als nicht reentrant (Non Reentrant) definiert [SWS_Dcm_01270]. Der Aufrufkontext muss daher gewährleisten, dass Aufrufe sequenziell und ohne nebenläufige Überlappungen erfolgen.

Die Callout-Funktion Xxx_ProcessRequestDownload ([SWS_Dcm_00754]) wird vom Modul Dcm aufgerufen, um bei der Verarbeitung des UDS-Dienstes RequestDownload einen Download-Vorgang zu initiieren. Sie ist als asynchron und nicht reentrant definiert und wird über den Header Dcm_Externals.h bereitgestellt ([SWS_Dcm_00754]).

Verwendung und Parameter

Der Aufruf erfolgt schrittweise über den Parameter OpStatus mit den Werten DCM_INITIAL, DCM_PENDING oder DCM_CANCEL ([SWS_Dcm_00754]). Als Eingabeparameter werden Kompressions- und Verschlüsselungsverfahren (DataFormatIdentifier), der Speicherblock (MemoryIdentifier), die Startadresse (MemoryAddress) und die unkomprimierte Speichergröße in Bytes (MemorySize) übergeben ([SWS_Dcm_00754]). Vor dem Aufruf beschreibt das Dcm den Inout-Parameter BlockLength mit der maximal möglichen Puffergröße ([SWS_Dcm_01417]). Die Funktion passt diesen Wert auf die maximal zulässige Blocklänge für spätere Schreiboperationen an ([SWS_Dcm_00754]).

Rückgabewerte und Zusammenspiel

Die Funktion liefert E_OK bei erfolgreicher Ausführung, DCM_E_PENDING, falls die Bearbeitung noch andauert, oder E_NOT_OK bei einem Fehler ([SWS_Dcm_00754]):

• Liefert der Aufruf E_OK und ist der verhandelte Wert BlockLength kleiner oder gleich der unterstützten Pufferlänge der aktuellen Protokollverbindung, sendet das Dcm eine positive Antwort mit diesem Wert als maxNumberOfBlockLength ([SWS_Dcm_01419]).
• Übersteigt die zurückgegebene Pufferlänge die unterstützte Puffergröße der Protokollverbindung, meldet das Dcm den DET-Fehler DCM_E_INTERFACE_BUFFER_OVERFLOW ([SWS_Dcm_01418]).
• Bei Rückgabe von E_NOT_OK versendet das Dcm eine negative UDS-Antwort (NRC) mit dem im Ausgabeparameter ErrorCode gesetzten Wert ([SWS_Dcm_00754], [SWS_Dcm_00757]).

Die Callout-Funktion Xxx_ProcessRequestTransferExit wird vom DCM-Modul aufgerufen, um einen laufenden Download- oder Upload-Prozess im Rahmen des UDS-Dienstes RequestTransferExit zu beenden [SWS_Dcm_00755]. Die Deklaration der Schnittstelle wird über den Header Dcm_Externals.h bereitgestellt [SWS_Dcm_00755].

Verwendung und Semantik

Die Funktion wird asynchron betrieben und ist als nicht reentrant definiert [SWS_Dcm_00755]. Der Aufruf erfolgt unter Übergabe des aktuellen Ausführungsstatus OpStatus (mögliche Werte: DCM_INITIAL, DCM_PENDING oder DCM_CANCEL) [SWS_Dcm_00755]. Als Rückgabewerte vom Typ Std_ReturnType sind spezifiziert:

• E_OK: Der Transfer wurde erfolgreich beendet [SWS_Dcm_00755].
• DCM_E_PENDING: Die Übertragungsbeendigung ist noch nicht abgeschlossen und erfordert Folgeaufrufe [SWS_Dcm_00755].
• E_NOT_OK: Die Beendigung schlug fehl oder der Antwortpuffer ist zu klein [SWS_Dcm_00755].

Fehlerbehandlung und Zusammenspiel

Gibt die Operation Xxx_ProcessRequestTransferExit den Fehlerwert E_NOT_OK zurück, muss über den Ausgabeparameter ErrorCode ein negativer Antwortcode übergeben werden. Das DCM-Modul sendet daraufhin eine negative UDS-Antwort (NRC) mit genau diesem Fehlercode an das Diagnoseprüfgerät [SWS_Dcm_00759]. Bei einem Abbruchaufruf übergibt das DCM-Modul den Status DCM_CANCEL an die Funktion [SWS_Dcm_00755].