AUTOSAR Experte

Matthias Gerber schrieb:
> Hallo Zusammen,
>
> ich bräuchte einen AUTOSAR-Experten, dem ich gerne ein paar Fragen
> stellen würde. Gibts hier sowas?

Wieso stellst du nicht einfach mal die Fragen? Oder willst du ne private 
Audienz?

Ok,
Kann ich auch machen.
Es geht um das Thema Modemanagement. Genauer um die Ports "Mode Request 
Port" und "Mode Switch Port". Angenommen ich habe eine Statemachine in 
der Applikationsschicht. Diese soll z.B. vom Zustand "Heizung Aus" in 
den Zustand "Heizung Ein" wechseln, wenn der Heizungswiderstand 
plausibel ist und über CAN das Signal "Heizung Ein" gesendet wird.

Laut Spec müssten dann ja sämtliche SW-C´s welche irgendwelche Diagnosen 
durchführen oder Signale auswerten über die Statemachine Bescheid 
wissen.
Sprich, in welchem Zustand befindet sich die Statemachine und welchen 
Zustand fordere ich an wenn ich fertig bin.

Mir wäre es lieber, ich hätte eine Reihe von Transitionen, welche ich 
als RTE-Signal implementiere und in der Statemachine abfragen kann. Je 
nachdem welche Transitionen gesetzt sind schalte ich in den nächsten 
Zustand. dann bräuchte ich jedoch den Port "Mode Request Port" nicht.

Versteht ihr was mein Problem ist?

Ich denke es wäre auch wichtig zu wissen, um welche AUTOSAR Version und 
Revision es sich in deinem Fall handelt.

Gehe ich mal von AR 4.0.3 aus, würde ich sagen, du solltest dir mal 
ModeSwitchEvents ansehen:
-> eine Runnable einer SW-C setzt mittels Mode Switch Port einen 
aktuellen Zustand aus der Mode Declaration Group.
Der generierte Rte Code ist verantwortlich zu prüfen, ob es sich um eine 
Änderung (Transition) des Mode State handelt, und für diesen Fall 
eventuell vorhandene ModeSwitchEvents auszuführen. Welche dann in einer 
anderen SW-C über deren ModeRequestPort genutzt werden können um eine 
weitere Runnable zu starten.
Des Weiteren könnte man über Extended Mode API innerhalb der Runnable 
noch auf den jeweiligen Übergang (previous State, next State) prüfen um 
differenzierte Aktionen zu veranlassen.

Es empfiehlt sich zu diesem Thema das Studium der SWS_RTE.

Danke für die schnelle Antwort. Das hat mir erstmal weitergeholfen.
Ich werde mich weiter einlesen und ggf. nochmal melden.
Und ja, wir verwenden 4.0.3

Jetzt muss ich doch nochmal fragen.
Wo genau siehst du die Logik, die sagt, dass ich einen bestimmen Mode 
wechseln soll? Ich habe bisher immer die Statemachine für diese Funktion 
vorgesehen.

Also nochmal folgende Überlegung.
SWC_1 berechnet den Heizungswiderstand
SWC_2 bearbeitet die CAn-Signale

desweiteren gibt es für jede Transition ein RTE-Signal -> 
RteSig_R-Heizung und RteSig_CAN-Sig

Meine Statemachine prüft diese Transitionen zyklisch ab. Bei erfüllen 
aller weiterschaltbedingungen wird der Mode gewechselt. Beim Modewechsel 
werden die SW-C´s über den ModeSwitch benachrichtigt.

Dies ist mein bisheriges System. Wie genau soll es also nach AUTOSAR 
aussehen?

Ohne exakt zu wissen auf was du hinaus willst gibt es meist mehrere Wege 
um zum Ziel zu kommen. Diese müssen nicht mal geschickter oder 
ungeschickter sein.

Möchte man den Zustand einer applikativen Statemachine innerhalb einer 
SW-C Runnable einer anderen SW-C Runnable mit Hilfe der per AR 
definierten RTE Mittel mitteilen, bestehen folgende Möglichkeiten:

- InterRunnableVars schreiben und lesen (nur bei gleicher SW-C 
anwendbar)
- S/R Interface über Ports (polling, od. DataReceiveEvent)
- C/S Interface über Ports (n:1 Beziehung, Server in der Empfänger SW-C)
- ModeSwitch Interface über Ports (polling, od. ModeSwitchEvents bzw. 
ModeSwitchAckEvents möglich)

Es liegt also an dir welchen Weg du gehen möchtest.

Für Zustände (keine Daten mit denen gerechnet werden sollte) würde sich 
meiner Meinung nach das ModeSwitch Interface anbieten. 
ModeDeclarationGroups müssen nicht explizit indeziert und mit 
LiterlLabels befüllt werden.

Jedoch kenne ich auch sehr viele Konfigurationen und Implementierungen, 
welche sich der S/R Interfaces für diese Art von Aufgabe annehmen.