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? Was hast du denn studiert?
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.
SCM heisst auch Source Code Management oder was du kennst Supply Chain Management hier ist aber ersteres gemeint.
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: > 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. Wie stellst du dir das Code aufbringen und debuggen vor? Woran willst du erkennen das der Code fehlerhaft ist? MfG, https://www.inchron.de/fileadmin/INCHRON/3-PDFs/Collaboration-WS/110330_INCHRON_Collaboration_Workshop_Salzmann_BMW.pdf
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,
Der Job ist für Berufseinsteiger. Was muss bei euch im Leben schief gelaufen sein, dass ihr hier sowas schreibt?
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.