Versionskontrolle im EDA-Bereich Die neueste Erfolgsmethode im Hardwaredesign

Autor / Redakteur: Robert Huxel* / Holger Heller

Wenn es um einen potenziellen Neukunden geht, erstellen die meisten großen EDA-Anbieter in der Regel zunächst eine kostspielige Fallstudie des vorhandenen Systems. Als nächstes wird ein Field Application Engineer (FAE) entsandt, der auf manuellem Weg Code schreibt und implementiert. Das es auch anders geht beweist Altium mit einer neuen Herangehensweise.

Firmen zum Thema

Robert Huxel, Altium: verfügt über mehr als 25 Jahre Erfahrung in der EDA-Branche. Seit 2008 ist er in seiner Funktion als Industry Specialist – Enterprise Solutions für die Betreuung der Altium-Kunden in Europa zuständig.
Robert Huxel, Altium: verfügt über mehr als 25 Jahre Erfahrung in der EDA-Branche. Seit 2008 ist er in seiner Funktion als Industry Specialist – Enterprise Solutions für die Betreuung der Altium-Kunden in Europa zuständig.
(Bild: VBM-Archiv)

Obwohl eigentlich eine integrierte Lösung angestrebt wird, resultiert aus dem oben genannten Vorgehen stattdessen ein langwieriger und teurer Prozess, der häufig nicht einmal den Großteil der vom potenziellen Kunden gewünschten Funktionalität (speziell für die Versionskontrolle) integriert.

Leider bleibt das Thema Versionskontrolle bei der Ausbildung im Bereich der Elektronikentwicklung nur allzu oft außen vor, obwohl sich diese Technik als echte Erfolgsmethode erwiesen hat. Für Softwareentwickler ist sie heute etwas absolut Unerlässliches, denn die Programme haben mittlerweile einen so großen Umfang, dass immer größere Designteams erforderlich sind.

Bildergalerie

Jeder Versuch, einen derart großen Codeumfang ohne effektives Versionskontrollsystem in den Griff zu bekommen, ist klar zum Scheitern verurteilt. Erst mit einer Versionskontrolle ist es möglich, mehrere Teammitglieder parallel an einem Softwareprogramm arbeiten zu lassen, ohne Gefahr zu laufen, dass eine Person den Code eines anderen Teammitglieds versehentlich löscht oder überschreibt.

Der Mehrzahl der in der Elektronikindustrie tätigen Menschen ist klar, dass in den Softwareteams deutlich mehr Beschäftigte tätig sind als in den für die Hardware zuständigen Teams. Da den Hardwareteams also tendenziell weniger Personen angehören, hat es sich dort meist eingebürgert, sich für die Dokumentenkontrolle auf das schlichte Durchnummerieren der Versionen zu beschränken. Die Teammitglieder greifen gemeinsam auf Ordner in einem Server oder sogar in einem Aktenschrank zu. Angesichts dieser Organisation ist die Frage angebracht, ob man hier überhaupt schon von einer Versionskontrolle sprechen kann.

Komplexität der Softwareentwicklung

Die Softwareprogramme wurden in den letzten Jahren rasch immer umfangreicher und komplexer. Mit jeder neuen Software-Release musste der Code regelmäßig aktualisiert werden, um neue oder verbesserte Features zu integrieren oder Fehler zu korrigieren. Um hiermit fertig zu werden, setzt die Softwareindustrie auf modulare Designmethoden und damit auf eine Art der Wiederverwendung von Designelementen. Dieses modulare Design und die erneute Nutzung bestehender Elemente aber brachte wiederum neue Herausforderungen mit sich.

Die Unternehmen stellten fest, dass die Wiederverwendung vorhandener Softwaremodule zahlreiche Vorteile hatte. Unter anderem brachten die Module einen Gewinn an Zuverlässigkeit, denn schließlich hatte die wiederverwendete Software ihre Bewährungsprobe in realen Systemen bereits hinter sich. Auch die Prozessrisiken wurden dank der Wiederverwendung geringer, denn bei der existierenden Software waren die Funktionalität, die Risiken und die Kosten bereits bekannt.

Hinzu kommt, dass wiederverwendbare Software effektiven Gebrauch von Spezialisten macht, deren Know-how in der Software enthalten ist. Vielleicht das überzeugendste Argument für die Wiederverwendung aber war die schnellere Entwicklung, da weniger Zeit für Codierung und Validierung aufgewendet werden muss. Die Teams waren dadurch in der Lage, enger gesteckte Markteinführungs-Vorgaben zu erfüllen und in kürzeren Abständen neue Produktversionen herauszubringen.

Ganz ohne Probleme ließ sich die Wiederverwendung von Softwaredesigns indes nicht implementieren. Eine generalisierte Anwendung von Softwaremodulen scheidet nämlich schlichtweg aus, denn die Module müssen gepflegt werden und die Entwicklungsprozesse sind bei den nachfolgenden Releases anzupassen. Wiederverwendete Module können sich außerdem als zunehmend inkompatibel erweisen, wenn sich das System mit der Zeit verändert. Steigende Wartungskosten sind die Folge. Damit sie einen echten Nutzen haben, müssen die wiederverwendeten Elemente in der Bibliothek auffindbar und verstanden sein.

Gelegentlich sind sie auch anzupassen. Es kann sein, dass in späteren Versionen neue oder aktualisierte Designelemente ins Spiel kommen. Diese dürften mit großer Wahrscheinlichkeit Vorgaben und Abhängigkeiten mit sich bringen, denen die wiederverwendeten Elemente entsprechen müssen. Die vielleicht größte Herausforderung in einem IP-Ecosystem besteht jedoch in der Auffassung vieler Unternehmen, sie könnten und sollten die Komponenten umschreiben, um sie zu verbessern oder sich anzueignen.

(ID:40321440)