Ich habe die Möglichkeit auf eine Stelle als Softwareentwickler und
würde mich zunächst um die Software-Integration (Automotive ECU,
überwiegend Serie) kümmern.
Sehe ich das richtig, dass ich überwiegend damit beschäftigt sein werde
die Software von Kollegen auf das Steuergerät und mit einem Lauterbach
Debugger zum laufen zu bringen? Inklusive dem Prüfen der notwendigen
Normen?
Ich würde mich über ein paar Infos von Leuten mit Erfahrungen in dem
Bereich freuen. Hat euch die Arbeit gefallen? Ist es ein guter Einstieg
nach dem Studium? Danke im voraus.
blro schrieb:> Sehe ich das richtig, dass ich überwiegend damit beschäftigt sein werde> die Software von Kollegen auf das Steuergerät und mit einem Lauterbach> Debugger zum laufen zu bringen?
Nein. Du wirst hauptsächlich Branches im SCM mergen und die Ergebnisse
übersetzen. Dann die fertigen Binaries an die Kollegen zum Testen
zurückgeben. Daneben noch die ganzen Buchhaltungsaufgaben wie Issues im
Issue-Tracker verwalten.
Du wirst die Kollegen dann natürlich auch dazu anhalten müssen
mergefähige Ergebnisse zu produzieren und entsprechende Rückmeldungen
geben, wenn dies nicht der Fall ist.
möppel schrieb:> blro schrieb:>> Sehe ich das richtig, dass ich überwiegend damit beschäftigt sein werde>> die Software von Kollegen auf das Steuergerät und mit einem Lauterbach>> Debugger zum laufen zu bringen?>> Nein. Du wirst hauptsächlich Branches im SCM mergen und die Ergebnisse> übersetzen. Dann die fertigen Binaries an die Kollegen zum Testen> zurückgeben. Daneben noch die ganzen Buchhaltungsaufgaben wie Issues im> Issue-Tracker verwalten.> Du wirst die Kollegen dann natürlich auch dazu anhalten müssen> mergefähige Ergebnisse zu produzieren und entsprechende Rückmeldungen> geben, wenn dies nicht der Fall ist.
Würdest du "Branches im SCM mergen und die Ergebnisse übersetzen" etwas
näher erläutern? Ich habe da keine Erfahrungen und die Suchmaschine gibt
mir dazu noch nichts eindeutiges.
blro schrieb:> Würdest du "Branches im SCM mergen und die Ergebnisse übersetzen" etwas> näher erläutern? Ich habe da keine Erfahrungen und die Suchmaschine gibt> mir dazu noch nichts eindeutiges.
ich bin zwar nicht der Möppel, helf aber mal aus:
SCM meint eine Versionsverwaltung. Guck im Internet wenn du das nicht
kennst, dann stolperst du auch über den Begriff "Branch". "Mergen" heißt
nicht anderes als "zusammenführen" (siehe englisches Wörterbuch).
Tom E. schrieb:> blro schrieb:>> Würdest du "Branches im SCM mergen und die Ergebnisse übersetzen" etwas>> näher erläutern?>> Was hast du denn studiert?
70% Elektrotechnik (inklusive dem gesamten grundstudium, auch c,
mikroprozessortechnik, grundlagen inf usw.), 30% BWL.
Ich bin kein klassischer Informationstechniker. Daran kann es liegen,
aber deswegen frage ich. Meine Vita ist den verantwortlichen Personen
klar.
bei uns, großes C, ist es eher eine mischung aus beiden, wobei ich eher
sagen würde: das ganze zeugs lauffähig hinzukriegen(basis SW usw.) du
kriegst(meist aus matlab generiert) Code und schaust das er läuft.
Testen tuts dann wieder jemand anderer
Claus M. schrieb:> blro schrieb:>> Würdest du "Branches im SCM mergen und die Ergebnisse übersetzen" etwas>> näher erläutern? Ich habe da keine Erfahrungen und die Suchmaschine gibt>> mir dazu noch nichts eindeutiges.>> ich bin zwar nicht der Möppel, helf aber mal aus:>> SCM meint eine Versionsverwaltung. Guck im Internet wenn du das nicht> kennst, dann stolperst du auch über den Begriff "Branch". "Mergen" heißt> nicht anderes als "zusammenführen" (siehe englisches Wörterbuch).
SCM kannte ich bisher nur im Bezug auf Logistik und Ähnliches. Die
englischen Wörter und auch das Thema Versionsmanagement (z.B. Starteam)
sind/ist mir bekannt.
Ich konnte das alles nur nicht zu den Aufgaben der Leute im Bereich
Software-Integration zusammenbringen. Würdest du mir das anhand eines
Beispielprozesses mit Stichwörtern aufzeigen?
blro schrieb:> Würdest du mir das anhand eines> Beispielprozesses mit Stichwörtern aufzeigen?
Hast du denn wenigstens mal den Wikipedia-Artikel über SCM gelesen?
ffff schrieb:> bei uns, großes C, ist es eher eine mischung aus beiden, wobei ich> eher> sagen würde: das ganze zeugs lauffähig hinzukriegen(basis SW usw.) du> kriegst(meist aus matlab generiert) Code und schaust das er läuft.> Testen tuts dann wieder jemand anderer
Also ich bin bisher davon ausgegangen, dass es um folgendes gehen wird:
Ich kriege den in MATLAB/Simulink von Kollegen generierten Code, bringe
ihn auf das Steuergerät und debugge falls es nicht funktioniert.
Anschließend dann die Weitergabe per Versionsmanagement an die Tester
(falls das nicht auch zum Aufgabengebiet gehört).
Korrigiert mich, falls ich etwas vergessen haben sollte oder falsch
liege.
Es gibt typischerweise ein Versionsverwaltungssystem (Source Code
Management, SCM), wie z.B. SVN, GIT, ClearCase usw., in dem der
Quellcode eines Projekts aufbewahrt wird. Das Tool bewahrt sämtliche
Versionen dieser Dateien auf, die jemals hinzugefügt (eingecheckt)
wurden.
Aus diesem Quellcode wird regelmäßig ein (internes) Release mit einer
bestimmten Versionsnummer gebaut, z.B. Version 1.2.3. Alle
Dateiversionen, die zu diesem Release gehören, bekommen eine Markierung
(Label) mit der Versionsnummer 1.2.3. Das Release besteht dann z.B. aus
der Binärdatei der Anwendung.
Wenn ein Entwickler eine Änderung an dem Programm machen möchte, stellt
er als erstes das SCM auf seinem Entwicklungsrechner so ein, dass er
alle Dateien in der Version 1.2.3 sieht. Wenn er das Programm auf seinem
PC übersetzt, entsteht daraus ein Binary, das dem der offiziellen
Version 1.2.3 entspricht.
Jetzt kann er Änderungen am Quellcode vornehmen und auf seinem Rechner
bzw. der Zielhardware testen und debuggen. Diese Änderungen sieht
zunächst nur der Entwickler selbst, da er die Datei nur auf seiner
Festplatte geändert hat. Wenn die Änderung funktioniert, kann er sie in
das SCM hinzufügen (einchecken). Das macht er in der Regel aber nicht
direkt auf dem Hauptentwicklungszweig (Main-Branch), sondern auf einem
privaten Branch, so dass es keine Auswirkungen auf andere Entwickler
hat. Jetzt kann er noch weitere Änderungen vornehmen, testen und wieder
auf seinem privaten Branch einchecken.
Irgendwann ist er der Meinung, dass das Feature fertig ist und in das
offizielle Release integriert werden soll. Dazu liefert er die Änderung
an den Integrator (also an Dich). Das geschieht in der Regel über ein
Tool, das z.B. auch Anforderungen und Bugreports verwaltet. Falls die
Änderung einen Fehler behebt, kann die Lieferung also direkt mit dem
Fehler verknüpft und nachverfolgt werden, in welcher Version er behoben
wurde. Die Zulieferung besteht u.a. aus dem Namen des privaten
Entwicklungsbranches, der integriert werden soll, einer Beschreibung für
die Release-Notes etc.
Der Job des Integrators ist es, aus den ganzen Zulieferungen, die die
Entwickler gemacht haben, eine neue Version 1.2.4 zu bauen. Dazu fügt er
alle Änderungen aus den privaten Branches der Entwickler auf dem
Hauptbranch zusammen. Das nennt man "mergen". Falls zwei Entwickler
Änderungen an der gleichen Datei vorgenommen haben, muss die neue Datei
beide Änderungen enthalten. Das können Mergetools in vielen Fällen
automatisch, manchmal muss der Integrator den Konflikt aber auch von
Hand beheben. Wenn er es nicht alleine kann, muss er das Problem
zusammen in den Entwicklern lösen.
Wenn alles gemergt ist, versucht der Integrator, das Programm zu
kompilieren. Dabei kann es ebenfalls zu Fehlern kommen, die er selber
oder zusammen mit den Entwicklern behebt. Wenn der Build erfolgreich
war, gibt er das Binary der Testabteilung bzw. erledigt ein paar
einfache Tests ggf. auch selbst, z.B. ob es sich überhaupt installieren
und starten lässt.
Wenn alles funktioniert und die Testabteilung grünes Licht gibt,
veröffentlicht er das Release intern oder extern. Falls nicht, muss er
Rücksprache mit den Testern/Entwicklern/Projektmanagement halten, was
unternommen wird: Wer untersucht den Fehler, welche Lieferung ist
schuld, gibt man das Release trotzdem frei usw...
Sobald das Release 1.2.4 freigegeben wird, beginnt das Spiel von vorne.
Die Entwickler holen sich Version 1.2.4, nehmen Änderungen vor, liefern
sie an den Integrator und der Integrator baut Version 1.2.5.
Oft hat man auch mehrere Entwicklungsbranches parallel, z.B. eine
öffentlich freigegebene Version wird mit Bugfixes versorgt, eine neuere
wird gerade stabilisiert und steht kurz vor der öffentlichen Freigabe
und neue Features werden auf verschiedenen internen Entwicklungszweigen
vorangetrieben. Dann müssen Zulieferungen in mehrere Versionen
integriert werden oder ein bestimmter Entwicklungszweig in einen anderen
gemergt oder rebased werden, wobei dann ebenfalls wieder Konflikte
entstehen können, die mit den Entwicklern zusammen gelöst werden müssen.
Außerdem gehört zu dem Job wie gesagt auch, die Bugreports/Changerequest
zu verwalten, sie Entwicklern zuzuweisen und sich um die Buildumgebung,
Installer/Deployment der Software etc. zu kümmern. Selber größere
Änderungen am Code vorzunehmen und zu debuggen ist dagegen nicht
Kernaufgabe eines Integrators, je nach Unternehmen/Abteilung kann er
daran aber auch beteiligt sein.
blro schrieb:> Also ich bin bisher davon ausgegangen, dass es um folgendes gehen wird:> Ich kriege den in MATLAB/Simulink von Kollegen generierten Code, bringe> ihn auf das Steuergerät und debugge falls es nicht funktioniert.> Anschließend dann die Weitergabe per Versionsmanagement an die Tester> (falls das nicht auch zum Aufgabengebiet gehört).>> Korrigiert mich, falls ich etwas vergessen haben sollte oder falsch> liege.
Da fehlt eine Menge... das Hauptsächliche hat ja möppel schon mal
zusammengefasst.
"Ich kriege den in MATLAB/Simulink von Kollegen generierten Code" ist
das, was möppel mit "im SCM mergen" beschrieben. Du darfst dir das nicht
so vorstellen, dass die dir ihre Sources per USB-Stick oder Mail
schicken. Stattdessen checken die den Kram in ein Versionskontrollsystem
ein und du wirst dann diese Sources in deine Build-Umgebung
hineinbringen - sei es über Mergen oder Umkonfigurieren.
"bringe ihn auf das Steuergerät" ist so ein bisschen naiv gedacht... da
gibt's noch massenhaft anderen Kram, der dazwischen liegt. Das obige ist
das Bauen einer Lib. Diese lib wird dann auf eine AUTOSAR Basis-Software
aufgesetzt, und dieser Build wird dann vielleicht noch mal
parametrisiert.
Teilweise wird das Basteln der Basis-SW ausgelagert - d.h. der
SW-Integrator baut die lib und schickt sie an den Dienstleister der
diesen Kram übernimmt, d.h. eine RTE bastelt die zu deiner lib passt.
Damit das hin haut musst du vorher die Architektur kommunizieren, was in
AUTOSAR über arxml passiert (google es ruhig mal).
Und das Flashen auf's Steuergerät machst dann unter Umständen auch nicht
du - sondern die jeweiligen Fahrzeug-Verantwortlichen oder Applikateure.
Glaube ja nicht, dass du als Software-Integrator zwangsweise die ECU zu
sehen oder sogar in die Finger bekommst. Das kann, muss aber nicht sein.
möppel schrieb:> blro schrieb:>> Würdest du mir das anhand eines>> Beispielprozesses mit Stichwörtern aufzeigen?>> Hast du denn wenigstens mal den Wikipedia-Artikel über SCM gelesen?Hans schrieb:> Es gibt typischerweise ein Versionsverwaltungssystem (Source Code> ....
Vielen Dank für die klasse Beschreibung.
blro schrieb:> Würdest du "Branches im SCM mergen und die Ergebnisse übersetzen" etwas> näher erläutern? Ich habe da keine Erfahrungen und die Suchmaschine gibt> mir dazu noch nichts eindeutiges.
Und dir zahlt jemand Geld für deine Qualifikation? Na den Job scheinst
du ja noch nicht sicher zu haben. Immerhin. Aber eigentlich müsstest du
da noch Lehrgeld mitbringen. Wer so was fragt, hat doch noch nie
irgendwas mit SW-Entwicklung im weitesten Sinne zu tun gehabt. Aber dann
dick einen auf "Software-Integration" machen. E-Technik und BWL. Na
super. Dann bleib bei deinen Leisten. Ist ja furchtbar.
Cyblord -. schrieb:> zu tun gehabt. Aber dann> dick einen auf "Software-Integration" machen. E-Technik und BWL. Na> super. Dann bleib bei deinen Leisten. Ist ja furchtbar.
Ist das nicht der Sinn von starren Prozessen gemäß der 26262, dass man
an jede Stelle im Prinzip eine Putze setzen kann? Qualifizierte Leute
braucht man nur bei Agiler Entwicklung und Co.
blro schrieb:> Ich bin kein klassischer Informationstechniker.> Meine Vita ist den verantwortlichen Personen
^^^^^^^^^^^^^^^^^^^^^^^^^
> klar.
Nee nee die Verantwortung für die Erfüllung des Jobs liegt letztlich bei
dir.
Schließlich hat man Dich gefragt ob Du dir das zutraust und Du hast ja
nicht Nein gesagt.
MfG,
blro schrieb:> Der Job ist für Berufseinsteiger. Was muss bei euch im Leben schief> gelaufen sein, dass ihr hier sowas schreibt?
Es liegt an der Hitze. ;)
blro schrieb:> 70% Elektrotechnik (inklusive dem gesamten grundstudium, auch c,> mikroprozessortechnik, grundlagen inf usw.), 30% BWL.
... dann darf man solche Fragen schon stellen!
Würde die Firma einen Inf. oder SW-Ing. mit 3-5 J. Erfahrung in der
SW-Integr. einstellen, müßte sie dem 70k+ bezahlen.
