Notizen zum Projekt (-Praktikum) von Prof. Jürgen Plate

Entwurf von Mikrocontrollersystemen

Die Phasen eines Mikrocontroller-Projekts

Erkennbar ist, dass während der verschiedenen Phasen Hardware- und Softwareteile zunächst gemeinsam spezifiziert, dann jedoch getrennt voneinander entwickelt werden, um im Anschluß daran integriert zu werden. Zwei Dinge sind im Bild oben besonders zu beachten:

• Zum einen ist es der rege Informationsaustausch, der während der Phase 3 zwischen den Hardware- und Software-Entwicklem anzustreben ist. Denn gerade beim Feinentwurf werden viele Entscheidungen getroffen, die Systemgrößen betreffen, darunter:
  • Schnittstelleniriformationen,
  • Adressbelegungen,
  • Mikrocontrollerkenndaten,
  • Zeitverhältnisse,
  • Art des Interrupt-Handling
  • Durchsatz (vor allem bei Spitzenlast-Situationen).
  Hier ist besondere Sorgfalt nötig, denn Systemfehler werden oft erst viel später, nämlich in der Integrationsphase entdeckt, sobald Hardware und Software miteinander arbeiten müssen.
• Zum anderen fällt auf, dass die verschiedenen Phasen nicht nur sequenziell eine nach der anderen abgearbeitet werden, sondern dass es vielmehr zwischen den einzelnen Phasen Rückwirkungen gibt. Die einzelnen Phasen stellen sequenziell gesehen eine Zunahme des Detaillierungsgrades dar. Treten dabei Widersprüche auf, z. B. bei der Umsetzung einer im Pflichtenheft spezifizierten Funktion, die sich nur in anderer Form realisieren lässt so führt das ggf. zu einer Änderung des Pflichtenhefts!
  Die gestrichelt eingezeichneten Pfeile sollen diese Art von Rückwirkungen aufgrund von Konsistenzprüfungen verdeutlichen. Vielfach sind für solche "Revisions" strenge Verfahren genau vorgeschrieben. Werden diese Konsistenzprüfungen nicht oder nur nachlässig durchgeführt, so kann es bei den Abnahmetests beim Kunden deshalb zu unliebsamen Überraschungen kommen, weil er sich im Pflichtenheft eine andere Realisierung vorgestellt hatte, als diejenige, die ihm nun präsentiert wird. Wichtig ist also, dass alle vereinbarten Änderungen klar formuliert und schriftlich festgehalten sind.

Wie Sie in der Projekttechnik-Vorlesung gehört haben, verlangt jedes Entwicklungsprojekt - und sei es noch so klein - eine sorgfältige Planung. Diese umfasst nicht nur die Terminplanung, sondern auch die Resourcenplanung (Verfügbarkeit von Personal, Kapital, Fertigungskapazität, Werkzeugen etc.) und ihre Überwachung.

Die Entwicklungsphasen in Stichworten:

• Ist-Analyse und Soll-Konzept (Phase 0):
  Ausgehend von einer Idee bzw. Bedarfsanalyse (Marktanalyse) wird zunächst eine Bestandsaufnahme der Rahmenbedingungen vorgenommen, um daraus die wichtigsten Zielvorgaben für das Projekt zu formulieren. Hier ist viel Kreativität gefragt, weshalb hier kaum schematisch vorgegangen werden kann.
• Systemanforderungen (Phase 1):
  Vollständige Definition der Hardware- und Softwareanforderungen in einem verbindlichen Pflichtenheft; Beschreibung dessen, was zu realisieren ist. Das Pflichtenheft ist Bestandteil des Entwicklungs-Auftrags und deshalb so sorgfältig und detailliert wie möglich abzufassen.
• Systemgrobentwurf (Phase 2):
  Blockschaltbild der Funktion des Systems aufgeteilt in Hardware- und Softwarefunktionen, Beschreibung der Einzelfunktionen, Übergang zur Art und Weise der Realisierung (Abschätzungen der Größenordnungen, erste "Weichenstellungen").
  Festlegungen bezüglich der Hardware betreffen unter anderen die Vorentscheidungen zwischen Hardware- und Software-Aufgaben (welchen Teil der Aufgaben wie realisieren), die Auswahl eines Mikrocontrollers samt Entwicklungssystem und das Einplanen der notwendigen Prüfgeräte, darunter auch ggf. die Entwicklung spezieller Prüfeinrichtungen.
  Festlegungen bzgl. Software betreffen die Gliederung der zu bearbeitenden Aufgaben in überschaubaren Programm-Modulen, die Definition und Beschreibung der Module hinsichtlich ihrer Funktion, Ein- und Ausgabeparameter und des Verhaltens in Ausnahmesituationen, die Absprache mit den Hardware-Entwicklern über Software- und Hardware-Schnittstellen sowie die Entscheidung, ob ein fertiges Betriebssystem eingesetzt wird oder die Software dazu selbst erstellt wird. Dazu kommen die Definition von Testmodulen und die Kostenanalyse.
  Am Ende dieser Phase sollte das Konzept noch einmal gründlich geprüft werden, denn dies ist die letzte Gelegenheit, ohne allzu große Kosten noch größere Veränderungen vorzunehmen.
• Systemfeinentwurf (Phase 3):
  Aus den Ergebnissen des Systemgrobentwurfs wird nun funktionsfähige Hard- und Software. Ziel des Hardwarefeinentwurfs ist der Aufbau eines Prototyps. Entwurf der Schaltung, Erstellung der Unterlagen für Fertigung und Test: Stromlaufpläne, Platinenlayout, Bestückungspläne, Steckerbelegungen, Verdrahtungspläne, Stücklisten.
  Ziel des Softwarefeinentwurfs ist die schrittweise Verfeinerung der Module (siehe allgemeine Entwurfsregeln), die Auswahl der Programmiersprache und der Entwicklungsumgebung sowie das Erstellen von Testprogrammen für den Hardwaretest.
• Integrationsphase (Phase 4):
  Systemfeinentwurf und Integration können allmählich ineinander übergehen, d. h. der Test einzelner Teile kann bereits ohne den komplett fertiggestellten Hardware-Prototyp erfolgen, wenn mit einem Entwicklungssystem gearbeitet wird. Die noch nicht fertigen Teile werden entweder nicht benötigt oder durch das Entwicklungssystem emuliert bzw. simuliert.
• Fertigung (Phase 5):
  Nach erfolgreich abgeschlossenem Integrationstest kann mit der Fertigung von HW und SW begonnen werden. Bei großen Stückzahlen und dem damit verbundenen Risiko hoher Kosten bei evtl. notwendigen Änderungen wird zunächst eine kleine Serie gefertigt und gründlich unter Original-Einsatzbedingungen erprobt (also keine "Bananentaktik": Grün ausliefern und beim Kunden reifen lassen).
  • HW-Fertigung: Herstellung von Leiterplatten, Bestücken, Prüfen, Zusammenbau, Endprüfung.
  • SW-Fertigung: Herstellung von PROMs, EPROMs, Masken-ROMs, Gesamtssystemtest
• Installation (Phase 6):
  Installation des Systems am Einsatzort und Prüfung aller im Pflichtenheft verlangten Leistungsmerkmale. Häufig treten nun Probleme aufgrund ungenauer Auslegung des Pflichtenhefts auf und erfordern Nachbesserung usw. Selbst nach gründlicher Abnahmeprüfung bleiben Fehler im System zunächst unentdeckt. Erst im Betrieb tauchen die letzten Fehler auf und müssen protokolliert, lokalisiert und beseitigt werden (siehe oben "Bananentaktik").
  Außerdem wird vielfach erst jetzt festgestellt, dass einzelne Funktionen verbesserungsbedürftig sind, d. h. Systemänderungen verlangt werden. Wie schwierig solche Änderungen nachträglich zu realisieren sind, hängt weitgehend vom Systementwurf (Modularität, Struktur, Schnittstellen...) und von der Qualität der Dokumentation ab.

Allgemeine Entwurfsregeln

Es lohnt sich immer, beim Entwurf komplexer Systeme nach einem bewährten Schema vorzugehen. Es gibt eine Reihe von Entwurfsprinzipien, vor allem für die Software-Entwicklung, die zum Teil durch Programme unterstützt werden. Im Phasenmodell des ersten Abschnitts ist es vor allem der Systemgrobentwurf), der für die Qualität des zu entwickelnden Produkts ausschlaggebend ist. Hier und auch im anschließenden Feinentwurf sollte nach folgenden Regeln vorgegangen werden:

• Top-Down-Entwurfsprinzip
  Dieses sehr bekannte Entwurfsprinzip ist sowohl für den Hardware- als auch für den Software-Entwurf geeignet. Der Grundgedanke dabei ist die Zerlegung einer Aufgabe in Teilaufgaben. Begonnen wird beim Gesamtsystem, das zunächst in wenige grobe Blöcke unterteilt wird. Jeder dieser Blöcke wird wieder in kleinere Blöcke zerlegt und so fort, bis man schließlich bei einem Verfeinerungsgrad angelangt ist, der direkt realisierbar ist.
  "Oben" ("Top") steht die Frage, was das System leisten soll. Dieser Leistungsumfang wird möglichst genau im Lastenheft spezifiziert (in der Regel vom Auftraggeber). Das entsprechende Gegenstück des Auftragnehmers ist das Pflichtenheft. Darin werden die Aufgabenstellung und verschiedene Aspekte der Realisierung aus der Sicht des Auftragnehmers so klar und eindeutig wie möglich beschrieben.
  "Unten" ("Down") soll schließlich die Frage nach dem "wie" beantwortet und der Entwurf skizziert sein. Es ist wichtig, dass der Entwurfsprozeß für das ganze System wirklich bis "unten" durchgezogen wird, bevor mit der Realisierung begonnen wird, denn nur so können falsche Wege beim Vorgehen von oben nach unten noch mit vertretbarem Aufwand korrigiert werden, wenn sich zeigt, dass sie zu keinen guten Lösungen führen. Notwendig ist also neben einem gewissen Mass an Durchhaftevermögen der Mut zum 'Wegwerfen' von Entwürfen, die sich als nicht tragfähig erwiesen haben.
• Bottom-Up-Prinzip
  Das Gegenstück zum Top-Down-Verfahren heißt "Bottom-Up-Verfahren" und geht den genau umgekehrten Weg. Ausgehend von einer soliden Kenntnis der verfügbaren Bausteine und -gruppen kann ein Entwurf von sehr erfahrenen Entwicklern auch "von unten her" angegangen werden. Die Chance, mit dieser Methode das gesteckte Ziel zu erreichen und dabei eine gut strukturierte Lösung zu erhalten, ist jedoch wesentlich geringer, speziell für den weniger geübten Entwickler. Beide Verfahren können sich in idealer Weise ergänzen, wenn mit dem Top-Down-Verfahren begonnen wird, und ab einem bestimmten Verfeinerungsgrad mehr und mehr an einzusetzende Bausteine und -gruppen gedacht wird (dieser Prozeß läuft mit zunehmender Erfahrung ohnehin mehr oder weniger intuitiv ab). Es lohnt sich aber in jedem Fall, die Top-Down-Vorgehensweise so oft wie möglich - auch an kleineren Aufgaben - zu trainieren.

• Spezifikation des "Mengengerüsts": Die Anzahl und Art der zu erfassenden bzw. zu verarbeitenden Daten sowie ihre typischen mittleren und maximalen "Ankunftsraten" gehören mit zu den wichtigsten Entwurfskriterien; "Worst Case" beachten! Bei der Hardware gilt das entsprechend, beispielsweise für maximale Eingangsfrequenzen oder Verlustleistung von Interface-Bausteinen.
• Alternative Realisierungsmöglichkeiten durchdenken! Es gibt fast immer verschiedene Wege zum Ziel und nicht immer ist die naheliegendste Lösung auch die beste. Selbst für so scheinbar klare und einfache Aufgaben wie die Stromversorgung eines Gerätes gibt es eine Fülle von Varianten!
• Eine möglichst weitgehende Unabhängigkeit der Blöcke ist anzustreben; d. h. Änderungen in einem Block sollen möglichst keine Auswirkungen auf andere Blöcke haben. Man kann das auch daran erkennen, wie die Schnittstellen zwischen den Modulen gestattet sind, denn: je weniger Signale bzw. Parameter über Schnittstellen transportiert werden müssen, um so selbständiger bearbeitet das Modul eine in sich geschlossene Aufgabe; deshalb:
  • Die Anzahl und der Aufbau dieser Schnittstellen ist zu minimieren, d. h. je weniger Interaktion zwischen Modulen, umso geringer ist auch die Wahrscheinlichkeit von Fehlern. An unnötig komplizierten Schnittstellen treten die häufigsten und die schwierigsten Fehler auf.
  • Die Schnittstellen zwischen den einzelnen Blöcken (Modulen) müssen genau definiert sein; auf diese Weise können die einzelnen Teile problemlos von verschiedenen Teammitgliedem entworfen werden. Es genügt dann, nur die Schnittstellen der Mockile zu kennen, zu denen Verbindungen des eigenen Moduls bestehen; in welcher Weise diese *fremden" Module realisiert sind, muß nicht bekannt sein. Moderne Programmiersprachen (OOP) unterstützen diese Methode.
• Die eigentliche Realisierung (Programmierung, Zeichnen der Schaltung) sollte so spät wie möglich beginnen. Je mehr Zeit in den Entwurf investiert wird um so erfolgreicher wird das Projekt, weil die Realisierung dann ohne Probleme läuft. Das "Brown'sches Paradoxon" besagt: "Je später mit der Implementierung begonnen wird, desto erfolgreicher wird das Projekt". Grenzfall?
  
  
  
  
  Die frühen Projektphasen sind von ausschlaggebender Bedeutung für den Projekterfolg: “Sage mir wie Dein Projekt beginnt und ich sage Dir, wie es endet”
• "Hardest First": Geht man die schwierigsten Tellaufgaben zuerst an, stößt man frühzeitig auf eventuell notwendige Änderungen am Gesamtkonzept, und muß nicht bereits verfeinerte leichtere Teilprobleme erneut bearbeiten.
• Vermeiden von "Rucksäcken": Nachgeflickte Ergänzungen sind häufig ein Zeichen eines schlechten Entwurfs. Sie passen schlecht ins ursprüngliche Konzept und zerstören die Struktur. Werden diese Rucksäcke immer mehr, dann sollte das Konzept neu überdacht und geändert werden, auch wenn es schwer fällt. Je später einFehler erkannt und beseitigt wird, um so mehr Aufwand ist damit verbunden.
• Den Entwurf von vomeherein "lesefreundlich" gestalten und an mögliche Fehler denken, "robust" entwerfen.
• Alle Sonderfälle berücksichtigen (Hochlauf, Ausnahme- und Fehlersituationen - auch "exotische"), defekte Sensoren, gestörte Signale von außen, Sicherheits- und Zuverlässigkeitsaspekte, Plausibilitätskontrollen, Schadensbegrenzung.
• Keine "Tricks" einbauen, die von Nachfolgern, Servicetechnikern - und manchmal von einem selbst - nach einiger Zeit nicht mehr verstanden werden. (Zumindest sollte man die Tricks sehr auffällig und gut dokumentieren!).
• Vorhandene Hilfsmittel nutzen, z. B. höhere Programmiersprachen, Betriebssysteme, Entwicklungssysteme, frühere Ergebnisse, Simulationstechniken, Programmbibliotheken. Jedoch ist der Einsatz von allen möglichen Tools, Methoden und Instrumenten eine notwendige, aber keinesfalls hinreichende Bedingung zur erfolgreichen Projektrealisierung.
• Auf schritthaltende Dokumentation achten. Sie fällt leichter, solange man noch mit den Einzelheiten vertraut ist. Also alle Entwicklungsschritte sofort dokumentieren. Nach Abschluß eines Projektes wird die Dokumentation meist ungenau, unvollständig oder gar nicht ausgeführt. Spätere Änderungen sind ohne gute Dokumentation praktisch nicht mehr durchführbar. Vor allem, wenn der Entwickler nicht mehr verfügbar ist, können enorme Kosten entstehen - bis hin zur kompletten Neuentwicklung! Außerdem ist eine saubere Dokumentation selbstverständlicher Bestandteil jeder Ingenieur-Arbeit! Bewußtes Nicht-Dokumentieren ("Kopf-Monopoil", "Job-Protection") ist ein zweischneidiges Schwert: der vermeintliche Vorteil (sich dadurch unentbehrlich zu machen) verkehrt sich ins Gegenteil: nach Abschluß einiger Projekte ist man nur noch mit der Wartung "seiner" alten Projekte beschäftigt und für Neuentwicklungen bleibt keine Zeit mehr. Gut dokumentierte Projekte können problemlos an Nachfolger übergeben werden.
• Für alle Projekte gilt, dass die Unterstützung durch das Top-Management mit der wichtigste Erfolgsfaktor ist. Dieses Ergebnis wird durch zahlreiche andere Studien bestätigt. Für den Projekterfolg genauso wesentlich ist die Zusammensetzung des Teams.

Realisierungsalternativien

Idealerweise kann man sich die Entwicklung eines dedizierten Systems wie das Zusammensetzen verschiedener LEGO-Bausteine vorstellen. Das Problem dabei ist nur, eine insgesamt wirtschaftliche Gesamtlösung zu finden. Abgesehen von ganz wenigen Projekten, wo der Kostenfaktor eine untergeordnete Rolle spielt (Raumfahrt, Militär), hat man im allgemeinen die verschiedenen Kostenanteile genau zu überdenken. Die wichtigsten davon sind

• Entwicklungskosten (Hardware und Software),
• Amortisation von Werkzeugen und Hilfsmitteln (Entwicklungssysteme, Mess- und Testgeräte),
• Herstellungskosten (Bauteile und Fertigung),
• Training für Vertrieb und Service und
• Folgekosten (Wartung, Servicepersonat, Ersatzteile, Lagerhaltung über Jahre).

Man unterscheidet in Bezug auf die "Einstiegsebene" grob zwei Realisierungsaltemativen: die Bauteil-Ebene (Eigenentwurf, Speziallösung) und die Baugruppen-Ebene (Systemlösung). Ein wichtiges Entscheidungskritedum stellt die zu erwartende Stückzahl dar.

• Eine Systemlösung, d.h. der Einsatz von möglichst vielen fertigen Komponenten, eventuell samt Gehäuse und Stromversorgung, bietet sich bei kleinen Stückzahlen an, wobei bewußt in Kauf genommen wird, dass die Kosten pro Stück etwas höher sein werden, weil damit in der Regel nur eine ungefähr passende Lösung (etwas zu groß) gefunden werden kann. Die Vorteile der Systemlösung liegen in der Überschaubarkeit des Hardwareaufwands und dem einfachen Test von Teilsystemen.
• Die spezielle Lösung "paßt" vom Bauteileaufwand her wesentlich genauer, hat also geringere Stückkosten, verursacht jedoch einen höheren Entwicklungsaufwand. Sie ist vor allem dann immer nötig, wenn es sich um ein echtes Massenprodukt handelt oder wenn die Randbedingenungen eine Systemlösung nicht zulassen.
• Häufig finden sich noch Zwischenlösungen z.B. in der Form, dass einige Komponenten (Prozessorkarte und Stromversorgung) fertig gekauft werden und die Ansteuerung von speziellen Peripheriegeräten selbst entwickelt wird.

Auswahl des Mikrocontrollers

Die wichtigste Rolle spielt der Controller selbst. Hier kann man zur Auswahl nach folgendem Schema vorgehen:

1. Erstellen Sie eine Liste der Hardwareanforderungen. Das geht recht einfach, wenn man sich eine Blockschaltung skizziert. Zum einen werden die Kommunikationsschnittstellen aufgelistet, beispielsweise sind dies 1 x USB, 1 x UART, 1 x I²C und 1 x SPI. Beim USB-Anschluss kann man auf externe Bausteine + UART ausweichen, wenn die CPU keine eigene USB-Schnittstelle besitzt. Statt 1 x USB und 1 x UART stände dann 2 x UART in der Liste (mit dem Nachteil, dass die endgültige Schaltung aufwendiger wird. Zum anderen werden die "einfachen" Schnittstellen aufgeführt, im Beispiel 7 x GPIO (digitale E/A) und 1 x ADC (Analog-Digital-Wandler).
2. Dann folgt eine Aufstellen der Anforderungen an die Softwarearchitektur. Hier sind Fragen zu klären wie Taktfrequenz und Mächtigkeit des Befehlssatzes (8 MHz Atmel Atmega oder 80 MHz DSP). Wird Gleitpunktarithmetik benötigt? Kann die Gleitpunktarithmetik emuliert werden oder muss sie der Prozessor in seiner Hardware implementiert haben. Mit welcher Frequenz müssen die digitalen und analogen Ein- und Ausgänge angesprochen werden? Hir darf man ruhig grob abschätzen, es kommt eher auf die Zehnerpotenz als auf einen exakten Wert an. Insgesamt muss also der Bedarf an Rechenleistung abgeschätzt werden.
3. Aufgrund der beiden vorhergehenden Punkte kann eine Entscheidung für den einzusetzenden Prozessor fallen. Dabei spielen wieder die Taktfrequenz, aber auch die Wortbreite (8, 16 oder 32 Bit), die Größe des Flash-Programmspeichers und des RAM eine Rolle. Denken Sie dabei auch etwas in die Zukunft. Nicht jeder Controller wird so lange produziert wie der 8051, der schon in den 1980er Jahren entwickelt wurde und immer noch lieferbar ist. Es kann auch durchaus vorkommen, dass das etwas "größere" 16-Bit-Modell weniger kostet als der 8-Bit-Controller aus der gleichen Familie.
4. Nicht nur die o. g. Kriterien spielen eine Rolle, sondern auch die Expertise im Haus. Tiefe Kenntnisse einer Controllerfamilie führen nicht nur zu kürzeren Entwicklungszeiten, sondern können auch "schlauere" Gesamtlösungen zur Folge haben. Aber auch hier sollte man offen für Neues sein und auch ganz unvoreingenommen alternativlösungen in Betracht ziehen. Mitunter ist die Auswahl des Controller ein iterativer Prozess. Auch der Energiebedarf kann eine Rolle spielen, beispielsweise bei Batteriegeräten oder akkugespeisten Datenerfassungssystemen.
5. Schließlich spielen auch noch Preis und Lieferbarkeit eine entscheidende Rolle. Hier spielt es eine Rolle, ob der ausgewählte Kandidat bei mehreren Distributoren erhältlich ist oder sogar von mehreren Herstellern produziert wird. Wie lange sind die Lieferzeiten? Sind auch größere Stückzahlen in angemessener Zeit lieferbar? Wie viele Jahre wird der Prozessor noch gefertigt?
6. Ist die Wahl auf einen "neuen" Controller gefallen, lohnt es sich, ein Entwicklungssystem zu kaufen, um die theoretisch ermittelten Eckpunkte auch an der realen Hardware zu testen. Gleichzeitig bekommt man ein Gefühl für die Handhabung des neuen Systems und stößt möglicherweise sogar auf ein K.O.-Kriterium. Gibt es kein Entwicklungssystem, sollte man die Wahl des Controllers ggf. überdenken.
   Bei der Gelegenheit kann auch gleich die Qualität und Bedienbarkeit von Compiler, Assembler, Debugger und anderen Tools zu testen. Gibt es eine IDE, eine integrierte Entwicklungsumgebung, oder nur einzelprogramme? Wie einfach ist das Übertragen des Programms in den Controller? Welche Programmieradapter werden benötigt? Was kosten die Softwaretools?
7. Last but not least: Starten Sie mit einem kleinen Projekt, einem Pilotprojekt. Erst wenn das erfolgreich mit allen Schritten gelaufen ist, fällen Sie die endgültige Entscheidung. Gestalten Sie das Pilotprojekt so, dass es möglichst die kritischen Kriterien erfüllt, die Sie bei der Vorplaung aufgestellt haben.

Sinngemäß kann bei der Software ebenso verfahren werden wie bei der Hardware: Betriebssystem bzw. "Echtzeitkem" eines Betriebssystems und evtl. eine Bibliothek von Standard-Programmroutinen kaufen und die anwendungsspezifischen Programme selbst entwickeln.

Neben den Kosten sind auch noch einige weitere Punkte zu beachten:

• Entwicklungszeit und Fertigstellungstermin: Der Erfolg eines Produktes wird oft mehr durch das rechtzeitige Erscheinen des Produktes auf dem Markt bestimmt, als durch seine Qualität. Bei Auftragsentwicklungen sind diese Termine ohnehin Eckwerte, deren Überschreitung fast immer mit finanziellen Verlusten verbunden ist.
• Risiko: Damit sind nicht nur eventuelle Probleme bei der Entwicklung der Hardware gemeint, sondern auch Koordinierungsschwierigkeiten z. B. bei der Vergabe von Fremdaufträgen (Platinenlayout, Platinentest etc.) oder beim Beschaffen von Bauteilen.

• Kenntnis des Marktes
• Fähigkeit, alle Kosten objektiv einzuschätzen (kein "Not invented here"-Syndrom)

Copyright © Hochschule München, FK 04, Prof. Jürgen Plate
Letzte Aktualisierung: