Two Pillars

Linkedin Youtube
Menü

Systemarchitektur

Die CONSENS Methode in iQUAVIS, Blog Titelbild mit Dr. Christian Bremer und Headline

Die Methode CONSENS in iQUAVIS

Schreibe einen Kommentar / MBSE, iQUAVIS, Two Pillars Blog /

In diesem Beitrag stellen wir die Umsetzung der Methode CONSENS in iQUAVIS vor. iQUAVIS lässt sich für die Umsetzung der CONSENS Methode speziell vorbereiten. Wir liefern das entsprechende Profil standardmäßig an unsere Kunden aus, die sich damit ihre konkrete CONSENS Umsetzung auch beliebig weiter anpassen können. Ein einheitlicher methodischer Rahmen ist dabei nicht nur wichtig, um in das Thema einzusteigen, sondern auch, um sicherzustellen, dass alle Modelle im Unternehmen vergleichbar sind. Nur so können sie letztlich wiederverwendet und ausgewertet werden. Mehr zum methodischen Hintergrund der Methode CONSENS finden Sie in unserem separaten Beitrag zu CONSENS. Übersicht zur CONSENS Methode Die CONSENS Methode ist gegliedert in zwei Phasen: Die Analyse- und die Synthese-Phase. In der ersten Phase arbeitet der Anwender mit Anwendungsszenarien, Umfeldelemente und Anforderungen. In der zweiten Phase sind es hauptsächlich Funktionen, Lösungselement und ggf. Verhalten. In iQUAVIS bieten sich Baumansichten an, um die Übersicht über die Phasen und die Traceability zwischen den Modellelemente zu überblicken. Neben den reinen Daten gibt CONSENS auch Bearbeitungsschritte vor, nämlich die schrittweise Erarbeitung der einzelnen Partialmodelle. iQUAVIS ermöglicht die Umsetzung solcher Vorgaben in der Prozesstabelle. Hier werden Aufgaben (standardisiert) definiert. Zu jeder Aufgabe gehören Sichten, in die der Nutzer direkt springen kann um so die Inhalte zu erarbeiten. Diese Sicht richtet sich daher an alle Nutzer und wird als Absprungebene in die einzelnen Aktivitäten genutzt. Umsetzung der Partialmodelle Die Partialmodelle von CONSENS werden in verschiedene Sichten in iQUAVIS umgesetzt. Für die Darstellung von Wirkstruktur und Umfeldmodell werden die Entity-Block-Diagramme verwenden. Für die Funktionshierarchie wird mit einer Baumansicht gearbeitet. Wie in CONSENS beabsichtigt, arbeitet iQUAVIS dabei auch mit starken optischen Unterscheidungselementen: So sind bspw. alle lösungsbehafteten Elemente (in iQUAVIS „Entity“) mit rechtwinkligen Ecken versehen. Lösungsneutrale Modellelemente wie bspw. Funktionen haben abgerundete Ecken. Auch mit Farben für Elemente oder Beziehungen kann gearbeitet werden. Die Verhaltensmodellierung wird ebenfalls mit den entsprechende Diagrammtypen ermöglicht. In den Bildern zu sehen sind die Sequenz-, Aktivitäts- und Zustandsdiagramme. Traceability und Nutzung der Methode CONSENS in iQUAVIS Die in CONSENS angefertigten Partialmodelle stehen nicht für sich alleine, sondern ergeben ein konsistentes Ganzes. Dazu werden die Modellelemente zueinander verknüpft. Beispielsweise ergeben sich Anwendungsszenarien oder Use Cases aus Umfeldelementen; Funktionen werden durch Systemelemente realisiert; Anforderungen werden mit Testfällen abgesichert. In der unten stehenden Grafik haben wir versucht, das so entstehende Systemmodell zu veranschaulichen. Insbesondere die Querbeziehungen bilden später die Grundlage für aussagekräftige Auswertungen: Wir haben dem Aufbau des Systemmodells einen eigenen Beitrag gewidmet: Das Systemmodell mit iQUAVIS Anpassung des CONSENS Profils Die CONSENS Methode ist gut geeignet um einen Einstieg in das Thema MBSE zu ermöglichen. Sobald man jedoch als Nutzer die ersten Projekterfahrungen gesammelt hat und Schritt für Schritt tiefer in das Thema einsteigt, stellt man in der Regel fest, dass es weitergehende Anforderungen an die Methode gibt. Beispielsweise werden weitere Anforderungsklassen notwendig, oder neue Sichten werden benötigt für bestimmte (bereits etablierte) Methoden. Diese Situation ist unser Erfahrung nach die Regel, denn letztlich gibt es immer unternehmensspezifische Aspekte, die der Branche, der Art der Projekte oder den Unternehmensstruktur geschuldet sind. Hier bietet iQUAVIS intuitiv zu bedienende Tools für die Erweiterung an. Neue Modellelement-Klassen oder neue Attribute können direkt im Tool erzeugt werden. iQUAVIS bietet dazu ein separates Administrationstool, mit dem Vorlagen und Profile zentral editiert und an alle Nutzer ausgerollt werden können. So kann auch dauerhaft sichergestellt werden, dass alle Nutzer mit den selben Modellelementen arbeiten und die Modelle so vergleichbar und standardisiert weiterverwendbar werden. Ihre Fragen? Haben Sie noch Fragen zur Methode CONSENS und wie iQUAVIS sie umsetzt? Fragen Sie uns gern über die Kommentarfunktion oder melden Sie sich für eine kostenlose Live Demo am Beispiel Ihres Use Cases an! Wir freuen uns auf Ihre Anfrage! Mehr über iQUAVIS erfahren Sie außerdem auf dieser Seite. Christian Dr. BremerDr. Christian Bremer ist Gründer und Geschäftsführer bei Two Pillars. Er verantwortet die Bereiche Entwicklung und IT, Administration und Personalwesen. Seit seiner Zeit beim Fraunhofer IEM beschäftigt sich Christian Bremer mit Model-Based Systems Engineering. Er berät und begleitet Unternehmen bei der Einführung. Dabei werden immer wieder auch neue Use-Cases und Feature in iQUAVIS implementiert. www.two-pillars.de/

Die Methode CONSENS in iQUAVIS Weiterlesen »

Rollen im Systems Engineering

11 Freunde – Rollen im Systems Engineering

Schreibe einen Kommentar / MBSE /

Aufgaben und Probleme gut zu analysieren und dann zielgerichtete Lösungen zu entwickeln – das ist Systems Engineering. Mit dieser wunderbaren Methodik verbessern und beschleunigen Sie Ihre Arbeit nachhaltig, auch, wenn Sie zunächst nur einzelne Methoden einführen. Selbst diese bringen bereits große Produktivitätssprünge, da Aufgaben nun explizit erledigt und dokumentiert werden. Dazu werden elf Rollen im Systems Engineering definiert, die von drei bis sieben Personen ausgeführt werden. In diesem Artikel stellen wir Ihnen die Rollen und ihre Aufgaben als Teil der Grundlagen des Systems Engineering vor. Systems Engineering als Chance für KMU Systems Engineering funktioniert am besten, wenn alle Rädchen ineinandergreifen – idealerweise (aber nicht notwendigerweise) wird dafür die Zusammenarbeit aller Beteiligten im Projekt optimiert: Hier liegt für kleine und mittlere Unternehmen eine besondere Chance, aber auch eine besondere Herausforderung! Systems Engineering setzt nicht nur auf die Trennung unterschiedlicher Zuständigkeiten im Rahmen des Prozesses – auch der Prozess selbst und, darüber hinaus, Unternehmensstrukturen ändern sich. Um Missverständnissen vorzubeugen: Wir von Two Pillars sind davon überzeugt, dass diese Veränderungsprojekte nicht zwingend notwendig sind, sondern auch „schon ein wenig Systems Engineering“ große Potentiale heben kann. Der Form halber wollen wir aber in diesem Beitrag diskutieren, wie Systems Engineering aus Sicht der beteiligten Rollen ausgestaltet sein sollte. Anforderungen an den Maschinenbau Die Anforderungen an den Maschinenbau sind hoch: Funktionsreichtum und Individualisierungsoptionen sorgen für eine steigende Produktkomplexität. Elektronik, Mechanik und Software treffen aufeinander, sodass bei der Entwicklung neuer Produkte eine Vielzahl von Herausforderungen gelöst werden muss. Varianz in den Produkten kommt hinzu: Der Baukasten als Lösungsansatz will beherrscht werden. Systems Engineering ist ein ganzheitlicher und interdisziplinärer Ansatz, um diese Anforderungen hinsichtlich Zeit und Ressourcen am besten zu erfüllen: Sie umschiffen elegant Fehlerquellen und vermeiden langwierige Testphasen, indem Sie die klassischen Methoden auf Systems Engineering umstellen – bzw. ergänzen. Aber Vorsicht: Dies revolutioniert nicht nur Ihre Produktentwicklung und Ihr Projektmanagement, sondern auch Ihr Unternehmen selbst. Für den deutschen, mittelständisch geprägten Maschinenbau liegen Chance und Risiko eng beieinander: Wie kann es gelingen, dass wenige, hoch qualifizierte Mitarbeiter diesen Anforderungen gerecht werden, und zwar, ohne die Arbeitsbelastung zu steigern, sondern sie bestenfalls zu senken? Vom klassischen Verständnis der einzelnen Rollen im Systems Engineering bewegen wir uns hin und versuchen mit Hilfe der Erfahrungen von Möhringer einen Transfer auf die Spezifika eines maschinenbaulichen Unternehmens. Rollen im Systems Engineering: Systems Engineering ist Teamwork Systems Engineering lastet nicht nur auf einer Person, Systems Engineering ist Teamwork! Den einen „Systems Engineer“ gibt es so gar nicht. In der Forschung und in der Praxis haben sich elf verschiedene Rollen herauskristallisiert, die von drei bis sieben Personen ausgefüllt werden. Bei der „Mutter aller Systems Engineers“, Sarah Sheard, sind es genau genommen zwölf Rollen – sie hat im Jahr 1996 dazu eine Analyse verschiedenster empirisch anzutreffender Aufgabenbereiche gemacht, die bis heute noch höchsten Anklang findet. Die Unterscheidung der verschiedenen Rollen ist besonders für kleine und mittlere Unternehmen wichtig, deren personelle Ressourcen begrenzt sind. Gewichtung und inhaltlicher Umfang der einzelnen Rollen fallen dabei sehr unterschiedlich aus und sind abhängig von Größe und Anforderung des Projekts. Auch variiert der zeitliche Einsatz der einzelnen Rollen, sodass die elf Rollen im Systems Engineering auf weniger Köpfe verteilt werden können. Im Folgenden gehen wir auf diese Rollen ein, wie sie von Sheard und Möhringer benannt werden. Zum Teil sind auch andere Bezeichnungen gebräuchlich. Wir verwenden die englischen Bezeichnungen, die auch weibliche Vertreter bezeichnen können. Requirement Owner (RO): Anforderungsmanagement Der Requirement Owners (RO) übersetzt Kundenanforderungen in spezifische Anforderungen. Im Wesentlichen findet der RO Antworten auf diese Fragen: Welche Systeme und Subsysteme müssen designt und gebaut werden? Dazu muss der RO auch die externen Schnittstellen verstehen und sicherstellen, dass die funktionale Architektur des zu entwickelnden Systems den Bedarf erfüllt. Dabei nimmt der Requirement Owner Einfluss auf das gesamte System inklusive seiner Subsysteme und ist auch für spätere Änderungen in den Anforderungen und deren Auswirkungen auf das System verantwortlich. Die Herausforderung, die sich bereits in diesem frühen Stadium der Produktentwicklung ergibt, ist die Gewährleistung der Traceability: Spätere Änderungen müssen lückenlos nachvollziehbar sein. Bei der Erstellung eines traditionellen Pflichtenheftes in einem Word-Dokument ist dies bei komplexen technischen Projekten kaum noch möglich, weswegen der Einsatz einer Software-Lösung für das Requirements Engineering mehr als ratsam ist. iQUAVIS wäre hier eine Möglichkeit, oder man kann Teile des Requirements Engineering mit einem entsprechenden Tool koordinieren. Über die Schnittstellen von iQUAVIS zu Requirements Managements Tools lesen Sie hier weiter. Die Rolle des Requirement Owners wird nach Möhringer bei kleinen Projekten dem oder der Vertriebsingenieur:in zugeordnet; bei mittleren und großen Unternehmen liegt die Rolle bei der Projektleitung. System Designer (SD): Systementwicklung Der System Designer (SD) tritt nach der Definition der funktionalen Anforderungen durch den Requirement Owner auf und ist für die Gestaltung von Architektur und Konzept zuständig. In diesem Stadium erschafft der System Designer die Systemarchitektur und trifft die Auswahl der wichtigsten Systemkomponenten. Der Schwerpunkt liegt bei der Zuordnung von Funktionen zu Elementen sowie ihrer Anordnung in eine Struktur. System Designer und Requirement Owner arbeiten in der Praxis oft zusammen: Ihre Rollen überschneiden sich vor allem bei der Auswahl der erforderlichen Subsysteme. Im Unternehmen wird diese Rolle von der Entwicklungsleitung oder einem Entwicklungsingenieur ausgefüllt. System Analyst (SA): Systemanalyse Der System Analyst (SA) trägt Sorge für die Erfüllung der Anforderungen im designten System. Darunter fallen z.B. das Systemgewicht, die Leistung, Durchsatz und Ausgabekenngrößen. Von sehr komplexen Bauteilen werden erste Modelle erstellt, um ihre Funktionen zu simulieren und um zu testen, ob sie so funktionieren werden, wie geplant. Die Systemanalyse kann auf den abstrakteren Ebenen bereits in iQUAVIS erfolgen. Logische Zusammenhänge, kleinere Berechnungen usw. können hier beispielsweise direkt erfolgen. Für komplexere Simulationen werden disziplinspezifische Werkzeuge genutzt, die mit den Daten aus dem SE-Tool versorgt werden. Validation and Verification (VV) Im Anschluss an die Simulationen plant und implementiert die Rolle des Validations- und Verifikationsingenieurs Testpläne und -prozeduren: Hier wird sichergestellt, dass das System die Anforderungen erfüllt. Diese Rolle wird aus dem Bereich Entwicklung ausgefüllt. In diesem Schritt geht es darum, alle Systemeigenschaften zu testen und etwaige Szenarien vorauszusehen. Auftretende Anomalien müssen bestmöglich beantwortet werden. Logistics and Operations (LO) Die Logistik- und Operationsrolle wird nach Möhringer auch den Entwicklungsingenieur:innen zugeordnet,

11 Freunde – Rollen im Systems Engineering Weiterlesen »

webinar systems engineering mit iquavis

Systems Engineering mit iQUAVIS – kostenloses Webinar

Schreibe einen Kommentar / iQUAVIS, Two Pillars Blog /

Systems Engineering ist ein ganzheitlicher und interdisziplinärer Ansatz für die Produktentwicklung und das Projektmanagement. Unser Consultant und MBSE-Experte Matthias Greinert hat in einem Live-Webinar über „Systems Engineering mit iQUAVIS“ gezeigt, wie der Einstieg in diese Methode mit unserem Tool iQUAVIS funktioniert. Der Einstieg in das Systems Engineering ist immer individuell – genauso wie Ihre Produkte und Ihre Kunden! Mit iQUAVIS können Sie Ihre individuellen Einstellungen ganz einfach anpassen und schnell erste Erfolge erzielen. In dem Webinar lernen Sie verschiedene Darstellungsformen in Berücksichtigung ihrer Anforderungen und Abhängigkeiten kennen. Falls Sie das Webinar verpasst haben, haben Sie jetzt die Gelegenheit, die Aufzeichnung anzuschauen und iQUAVIS kennenzulernen. Webinar abrufen Haben Sie das Live-Webinar verpasst, aber Interesse, es sich anzusehen? Kein Problem: Füllen Sie dieses Formular aus, und Sie erhalten den Link und das Passwort, um sich das Webinar kostenlos anzusehen: Systems Engineering mit iQUAVIS: Das Webinar Die Aufzeichnung des Webinars dauert ca. eine Stunde inklusive einer Fragerunde. Sollten Sie weitere Fragen haben, stehen wir Ihnen gern zur Verfügung. In dem Webinar stellt Matthias Greinert nicht nur iQUAVIS als Systems Engineering Tool vor und erläutert die wichtigsten Funktionen am Beispiel einer Kaffeemaschine, sondern er geht auch auf den Aufbau einer Systemarchitektur ein: Im Rahmen der Tool-Demo gibt er Einblicke in die verschiedenen Modelltypen, die iQUAVIS bietet und wie die darin modellierten Inhalte miteinander verknüpft und analysiert werden können. Dabei wird grob der Entwicklungsprozess von der Problemanalyse mit Identifikation von Anforderungen über die Definition der Systemarchitektur bis zur Ableitung von Testfällen durchlaufen. iQUAVIS bietet grundsätzlich die folgenden Darstellungsformen, die alle wenigstens kurz vorgestellt werden: Im Webinar lernen Sie die Funktionsweise von iQUAVIS kennen: Ausgehend von User Stories werden Abhängigkeiten und Anforderungen sichtbar. Matthias Greinert zeigt Ihnen, wie Sie Sichten kombinieren und Prozesszeiten simulieren. Er geht außerdem auf iQUAVIS als Projektmanagement-Tool ein und zeigt, wie Sie Maßnahmen, Ressourcen und Deadlines immer im Blick behalten. Zuletzt stellt er auch den Variantenmanager vor, ein Zusatz-Feature, das wir hier in Paderborn entwickelt haben, und das Ihnen von Projektbeginn an hilft, Varianten und ihre Abhängigkeiten darzustellen. In der Fragerunde ging es zum Abschluss um diese Fragen: Die Antworten gibt unser Experte Matthias Greinert im Webinar. Wenn Sie weitere Fragen haben, richten Sie sie gern auch im Nachhinein an uns. Weitere Webinare rund um MBSE Wir planen weitere Webinare rund um MBSE und iQUAVIS. Haben Sie Themenwünsche oder Fragen, auf die wir eingehen sollen? Schreiben Sie uns gern einen Kommentar! Die nächsten Webinartermine geben wir über unseren Newsletter, LinkedIn oder unsere Event-Seite bekannt! Sonja FeierabendSonja Feierabend ist Online Marketing Managerin bei der Two Pillars GmbH. Sie hat Literaturwissenschaft und Medienwissenschaft studiert und bloggt seit der Erfindung des Internets. Sie betreut die Website und Social Media sowie weitere Marketing-Themen, PR und Projekte. www.two-pillars.de

Systems Engineering mit iQUAVIS – kostenloses Webinar Weiterlesen »

iQBuddy

iQBuddy: So wird der Modellierungsprozess einfacher

Schreibe einen Kommentar / Forschung und Lehre /

Auf dem diesjährigen TdSE stellt Denis Tissen vom Heinz Nixdorf Institut den „iQBuddy“ vor: Was ist iQBuddy und was kann er? Die Modellierung komplexer technischer Systeme mit dem Konzept des Model-Based Systems Engineering (MBSE) ist für viele kein Fremdwort mehr. Steigende Anforderungen an die zu entwickelnden Produkte und deren vorherrschenden Systemmodellen spiegeln sich vor allem in den Tätigkeiten der Systemarchitekten wider. Anwender des MBSE müssen aktuell einen Großteil ihrer Modelle von Grund auf eigenständig aufbauen. So wiederholen sich viele Modellierungstätigkeiten, welche unnötig viel Entwicklungszeit rauben. Doch wie lassen sich wiederholenden Modellierungstätigkeiten sinnvoll unterstützen bzw. optimieren? Eine Antwort liefert iQBuddy. Was ist iQBuddy? Die Software-Anwendung iQBuddy dient als Assistent im komplexen, digitalen Modellierungsprozess. Mithilfe von gezielten Vorschlägen für erforderliche Bestandteile des Modellierungsprozesses unterstützt iQBuddy Anwender bei täglich anfallenden Modellierungsaufgaben. So müssen Systeme nicht mehr von „Grund auf“ auf modelliert werden. Es wird dabei auf vordefiniertes Wissen innerhalb einer Datenbank zurückgegriffen. Diese ermöglicht die Nutzung bereits erprobter Modellierungsbestandteile für die eigenen täglichen Modellierungsaufgaben. So kann durch iQBuddy nicht nur die Entwicklungszeit reduziert, sondern auch die eigene Perspektive erweitert werden. Wie genau funktioniert iQBuddy? Der Nutzen von iQBuddy wird bereits deutlich. Doch wie genau soll dies funktionieren? Gemäß dem Sprichwort: „Ein Bild sagt mehr als 1000 Worte“, lässt sich die Funktionsweise am besten in Form einer Abbildung erklären (siehe Abbildung 1). Das Architekturkonzept von iQBuddy zeight, dass Anwender Schlüsselwörter eines bestimmten Systems, Produkts oder andere Entitäten über eine Suchzeile in einer Webapplikation eingeben können. iQBuddy vergleicht diese Schlüsselwörter intelligent mit einer Modellbibliothek in Form einer Datenbank. Die graph-basierte Datenbank wird initial durch die KI-Anwendung ChatGPT mit Lösungselementen befüllt. Um die hohen Qualitätsanforderungen der Daten zu gewährleisten, werden die Lösungselemente durch Administratoren überprüft und angepasst. So gelingt es iQBuddy mit einem Empfehlungsalgorithmus, den Anwendern Elemente, Funktionen, Beziehungen und Strukturen für Systemmodelle vorzuschlagen. Anschließend erlaubt die Webanwendung, die vorgeschlagenen Datensätze auszuwählen und als JSON-File herunterzuladen. Somit findet eine nahtlose Importierung vorhandener Datensätze in gängige Modellierungswerkzeuge statt, wodurch eine eigene Modellierung dieser Systemelemente entfällt. Indem Anwender die vorgeschlagenen Datensätze akzeptieren oder ablehnen, wird der Empfehlungsalgorithmus intelligent trainiert. Dies verbessert kontinuierlich die Qualität der Vorschläge. Modellierungszeiten reduzieren, Qualität erhöhen Maßgeschneiderte Vorschläge lösen zeitintensive, lästige Modellierungsaufgaben ab, wodurch die Entwicklungszeiten reduziert werden. So können Anwender von iQBuddy ihre Modellierungsaufgaben effizient gestalten. Dadurch, dass die Vorschläge auf bewährten Systemelementen mit dem Wissen einer Community basieren, wird zudem die Modellqualität gesteigert. Außerdem wird die eigene Perspektive durch den Wissensbereich der Community erweitert, um neue Aufgabenbereich zu integrieren. Zusammengefasst bedeutet das: iQBuddy unterstützt Anwender effektiv bei ihren Modellierungsaufgaben. Dies ist ein Gastbeitrag von Denis Tissen. Er ist wissenschaftlicher Mitarbeiter im Advanced Systems Engineering am Heinz Nixdorf Institut der Universität Paderborn. Auf dem TdSE 2023 in Würzburg wird er den iQBuddy in einem Vortrag vorstellen. Wir stellen die Anwendung auch als Demonstrator näher vor. Besuchen Sie uns gern am Stand 30! Sonja FeierabendSonja Feierabend ist Online Marketing Managerin bei der Two Pillars GmbH. Sie hat Literaturwissenschaft und Medienwissenschaft studiert und bloggt seit der Erfindung des Internets. Sie betreut die Website und Social Media sowie weitere Marketing-Themen, PR und Projekte. www.two-pillars.de

iQBuddy: So wird der Modellierungsprozess einfacher Weiterlesen »

iQUAVIS 5.0

iQUAVIS 5.0

Updates, iQUAVIS /

iQUAVIS hilft Ihnen, komplexe Entwicklungsprojekte mit Hilfe von Systems Engineering zu meistern. Mit seinen Komponenten Systemarchitektur und Projektmanagement verschafft Ihnen iQUAVIS den entscheidenden Wettbewerbsvorteil. Bringen Sie Ihr Entwicklungsprojekt erfolgreich und schneller zum Abschluss! Die Version 5.0 von iQUAVIS beinhaltet viele spannende Neuerungen mit Fokus auf die Verbesserung von Arbeitsabläufen und Usability, so dass die Zusammenarbeit in Projekten noch reibungsloser verläuft. Insbesondere ist die nahtlose Zusammenarbeit mit Microsoft Office-Produkten gelingt nun noch besser. Einige Beispiele stellen wir heute vor. Action Priority Tables Jetzt auch Action Priority Tables mit iQUAVIS anwenden für Ihre FMEA konform mit VDA/AIAG Standard. Zur Priorisierung von Risiken wird in der FMEA die Schwere (Severity), Auftretenswahrscheinlichkeit (Occurance) und Entdeckungswahrscheinlichkeit (Detectability) bewertet. Das Produkt dieser drei Werte ergibt in der klassischen Form der FMEA die sogenannte Risikoprioritätszahl. Je höher diese Zahl, desto höher auch die Priorität, die diesem Risiko beigemessen wird. Dieses Vorgehen hat jedoch die Schwachstelle, das z.B. schwerwiegende Risiken eventuell zu gering bewertet werden, sofern die anderen beiden Werte niedrig sind. Dabei wäre bereits das einmalige Auftreten katastrophal. Im neuen Standard der VDA/AIAG werden anstatt der Risikoprioritätszahl Action Priority Tables genutzt. Hierbei wird mit Wertebereichen für die drei beschriebenen Einflussfaktoren gearbeitet. Auf diese Weise können Risiken realitätsnäher bewertet werden. Die Einordnung des jeweiligen Risikos erfolgt dann in eine der drei Kategorien – gering, mittel oder hoch. iQUAVIS unterstützt beide Varianten der FMEA, Im folgenden Bild ist dargestellt, wie zusätzlich zur herkömmlichen Methode nun auch die Dimension der Action Priority betrachtet und mit in die Bewertung einbezogen wird. Individualisierte Aufwandsplanung Aufgabendauer präziser planen! Ein und dieselbe Aufgabe kann je nach Erfahrung des zugewiesenen Mitarbeiters schneller oder langsamer bearbeitet werden. Wenn man diesen Faktor in der Aufgabenplanung nicht berücksichtigt, führt das zu Fehlplanungen. Mit Hilfe von Faktoren, die den Erfahrungsgrad der Mitarbeiter widerspiegeln, ermöglicht iQUAVIS eine realistische Planung der Aufgaben auch bei Wechsel der Zuständigkeit. Nehmen Sie als Beispiel eine Aufgabe, für die im Schnitt 6 Personentage benötigt werden. Teilt man nun diese Aufgabe gleichmäßig auf drei verschiedene Ressourcen auf, ergibt sich als Basis zur Berechnung der Gesamtdauer dieser Aufgabe folgendes Bild: Eine Ingenieurin erledigt ihren Teil der Aufgaben in zwei Tagen (Faktor 1) und ein Senior Engineer erledigt seinen Teil der Aufgaben in 1,4 Arbeitstagen (Faktor 0,7). Ein Junior Engineer benötigt dagegen 3 Arbeitstage für seinen Teil (Faktor 1,5).  Insgesamt wird die Aufgabe bei gleichmäßiger Verteilung in 6.5 Tagen erledigt sein. iQUAVIS nutzt diese Faktoren bei der Zuweisung von Aufgaben und ermöglicht so eine deutlich realitätsnähere Planung. Die Faktoren dienen dabei rein der Einstufung des Erfahrungsgrads und nicht als Einzelbewertung der individuellen Mitarbeiter. Mit diesem Feature erweitern sich für den Projektplaner die Möglichkeiten der Aufgabenplanung. Außerdem sind die Erwartungen an die Mitarbeiter transparent und nachvollziehbar. Automatisiertes Einfärben von Elementen: Neue Möglichkeiten der Visualisierung Wir arbeiten in iQUAVIS bewusst mit Farben, um Unterschiede zwischen Klassen, Datensätzen u.a. zu visualisieren. Es ist jetzt möglich Modellelemente per Knopfdruck einzufärben. Diese Einfärbung kann auf Basis von Klassen, Datensätzen oder benutzerdefiniert erfolgen. So kann schnell überblickt werden, welche unterschiedliche Klassen oder Datensätze in einem Modell vorhanden sind. In Diagrammen und Bäumen ist es jetzt möglich, zwischen verschiedenen farblichen Darstellungen zu wechseln. Die folgenden Bilder zeigen die Möglichkeit, in Diagrammen zwischen Farben Bäume ermöglichen den Wechsel zwischen Klassen- und Datensatz-Darstellung. Aus der Kombination aus Klassen und Datensätzen ergeben sich interessante neue Möglichkeiten zur Darstellung Ihrer Modelle. Microsoft Outlook und iQUAVIS synchronisiert Sparen Sie Arbeitsschritte  =  Sparen Sie Zeit! Aufgaben werden in iQUAVIS bisher im Home-Screen oder im Projekt übersichtlich dargestellt. Mit der neuen iQUAVIS Version können Mitarbeiter bei neuen Aufgaben direkt per E-Mail informiert werden. Der Mitarbeiter kann mit dieser Mail direkt in das iQUAVIS Projekt navigieren oder sogar die Aufgaben unmittelbar in der Mail quittieren. Die Aktualisierung der Aufgaben wird direkt mit dem iQUAVIS Projekt synchronisiert. Die Notwendigkeit, iQUAVIS zu öffnen und manuell die Information hinzuzufügen, d.h. den Aufgabenstatus auf „erledigt“ zu setzten, entfällt. Dadurch wird die Aufgabenbearbeitung in iQUAVIS noch effektiver in den Arbeitsalltag integriert. Mit diesem Feature machen Sie einen großen Schritt in Richtung verbesserte Workflows und nahtlose digitale Prozesssteuerung! Insbesondere auch die Kombination mit dem Microsoft Teams-Connector „2Psync“ bietet dann eine ganzheitliche Kommunikationslösung zwischen Technik und Projekt. Single Sign-on (SSO) mit Microsoft Azure Machen Sie sich das Arbeitsleben einfacher, indem Sie die Single Sign-on (SSO) Methode mit Microsoft Azure nutzen. Ohne SSO müssen Sie sich bei jedem Start von iQUAVIS mit Ihrem Benutzernamen und einem (hoffentlich anspruchsvollem) Kennwort einloggen.Mit SSO, können Sie sich diesen Schritt in Zukunft sparen: Nachdem Sie sich wie gewohnt beim Start Ihres Computers in ihr Windows-Konto eingeloggt haben, brauchen Sie iQUAVIS nur noch zu starten und können direkt loslegen, ohne zusätzliche Passworteingabe. Die Authentifizierung wird im Hintergrund über Microsoft Azure abgewickelt. Das ist nicht nur bequemer sondern auch sicherer. Denn so entfällt das „Passwort-Wirrwarr“ und Logins können zentral verwaltet werden. Christian Dr. BremerDr. Christian Bremer ist Gründer und Geschäftsführer bei Two Pillars. Er verantwortet die Bereiche Entwicklung und IT, Administration und Personalwesen. Seit seiner Zeit beim Fraunhofer IEM beschäftigt sich Christian Bremer mit Model-Based Systems Engineering. Er berät und begleitet Unternehmen bei der Einführung. Dabei werden immer wieder auch neue Use-Cases und Feature in iQUAVIS implementiert. www.two-pillars.de/

iQUAVIS 5.0 Weiterlesen »

MBSE SE Maennchen Systems Engineering

Das SE-Männchen einfach erklärt

MBSE /

Der Begriff Model-Based Systems Engineering (MBSE) ist inzwischen in aller Munde. MBSE mehr als nur formales Modellieren am Rechner. Es ist Teil einer ganz eigenen übergeordneten Strategie und Vorgehensweise – dem Systems Engineering. Das wird häufig übersehen. Ähnlich wie bei Lean Production kann man natürlich einzelne Methoden und Werkzeuge wie 5S-Methode oder Fischgrät-Diagramme wirkungsvoll selektiv einsetzen. Richtig erfolgreich wird eine Produktion aber nur neu gestaltet, wenn es sich auf den Lean-Ansatz von Kopf bis Fuß einstellt.

Das SE-Männchen einfach erklärt Weiterlesen »

ISO/IEC/IEEE 42010 ISO 42010 Systemarchitektur

Die ISO/IEC/IEEE 42010 – Software und Systems Engineering

MBSE /

Im Bereich des Systems Engineering gibt es eine Vielzahl von Normen und Standards, die verschiedene Aspekte des Systementwurfs und -managements abdecken. Diese Normen dienen als Referenz und Leitfaden für Ingenieure, um effektive und zuverlässige Systeme zu entwickeln. Aus unserer Perspektive ist die ISO/IEC/IEEE 42010 die wichtigste: Sie ist von Ihrer Denkweise und Art die ungewöhnlichste und gleichzeitig der größten Hebelwirkung auf die Verbesserung der digitalisierten Zusammenarbeit. Die ISO/IEC/IEEE 42010 präsentiert Best Practices, um eine Systemarchitektur zu beschreiben – egal ob Mechatronik, Software oder von Unternehmen. Die ISO/IEC/IEEE 42010 Ceci n’est pas une pipe – das bekannte Ölbild des Malers René Magritte zeigt ein (für das Erscheinungsjahr nahezu photorealistisches) Abbild einer Pfeife, untertitelt mit dem französischen Satz „Ceci n’est pas une pipe“, zu Deutsch: Dies ist keine Pfeife. Magritte beschreibt mit seinem Bild die Beziehung zwischen dem tatsächlichen Objekt, seiner Bezeichnung und seiner graphischen Repräsentation – Sie sehen keine Pfeife, sondern nur ihr Bild. Genauigkeit der Begriffe Warum dieser kleine Exkurs? Gerade beim Thema „Architektur“ ist Genauigkeit gefragt. Die ISO/IEC/IEEE 42010 Systems and Software Engineering – Architecture Description schafft ein einheitliches Verständnis für die Begriffe im Kontext einer Systemarchitektur. Das Bild der Pfeife deutet da auf ein häufiges Missverständnis hin: Wir sagen meist Architektur – meinen aber die Architekturbeschreibung eines Systems. Konzept der ISO 42010 ISO 42010, mit dem Titel „Systems and software engineering – Architecture description“, konzentriert sich speziell auf die Beschreibung von Architekturen. Sie legt Prinzipien und Konzepte fest, um sicherzustellen, dass Architekturbeschreibungen klar, konsistent und verständlich sind. Die Norm bietet Anleitungen zur Strukturierung, Dokumentation und Kommunikation von Architekturen und ermöglicht es Ingenieuren, die Architektur eines Systems umfassend zu verstehen und zu analysieren. Die ISO/IEC/IEEE 42010 liefert also ein Rahmenwerk für die Beschreibung, Organisation und Darstellung von Architekturbeschreibungen. Sie löste 2007 die IEEE 1471 Recommended Practice for Architectural Description of Software-Intensive Systems ab und adressiert seitdem jegliche Systeme – insbesondere natürlich technischer Art. Die ISO 42010 wird unabhängig von technischen Konzepten, Modellierungssprachen oder Werkzeugen beschrieben. Diese Neutralität ermöglicht die Übertragung auf das eigene Unternehmen und schafft somit eine einheitliche Arbeitsgrundlage. Unter einer Systemarchitektur versteht die Norm die fundamentalen Konzepte oder Eigenschaften eines Systems, also beispielsweise wie es in seine Umgebung eingebettet ist, was seine konstituierenden Elemente und ihre Interaktionen sind sowie die Prinzipien, nach denen es entwickelt und organisiert wird. Eine Architektur ist etwas Abstraktes, ihre Beschreibung dagegen ein konkretes Arbeitsprodukt in der Produktentwicklung. Das Modell der Architekturbeschreibung Kern der ISO ist eine Ontologie. Elementar ist hier das Zusammenspiel zwischen einem Stakeholder, dem betrachteten System (‚System-of-Interest’) und der Architekturbeschreibung: Einer oder viele Stakeholder der Architekturbeschreibung haben unterschiedliche Interessen an einem System. Die daraus abgeleiteten Concerns finden dann Berücksichtigung in der der Architekturbeschreibung. Der Begriff Concern ist etwas ungelenk definiert als ‚any topic of interest’ – beispielsweise die Funktionalität, die Struktur, das Verhalten des Systems (weitere Concerns in der Infobox). Zur Befriedigung eines Concerns wendet die ISO 42010 das Konzept der ‚Separation of Concerns’ an – jeder Concern wird durch eine einzelne View (Sicht) dargestellt, also einen konkreten Ausschnitt der Architekturbeschreibung in einer hierfür geeigneten Darstellungsweise. Das kann etwa für den Systemingenieur eine Wirkkette sein, für den Elektrotechniker das Blockschaltbild und für den Projektmanager durchaus eine N2-Matrix. Die in den verschiedenen Views zum Ausdruck gebrachten Inhalte können sich durchaus überschneiden – da sie jeweils ausdrücken, was für den konkreten Stakeholder ‚von Interesse’ ist. Wie die View dargestellt und erarbeitet wird, wird durch den Viewpoint (Standpunkt) bestimmt. Dieser definiert die Konventionen zur Erstellung, Interpretation und Analyse der Views. Das sind etwa Sprachen, Notationen, Modellart, Modellierungsmethoden oder Analysetechniken. Ein Architecture Viewpoint ist somit im Prinzip eine Beschreibung der Methode zur Erstellung einer konkreten View. Verwendung von Architekturbeschreibungen Eine konsistente Architekturbeschreibung, über die verschiedenen Views hinweg, ist oberstes Ziel in der Produktentwicklung. Modellbasiertes Systems Engineering (MBSE) bietet hierfür in vielen Fällen die notwendige Herangehensweise. Die Architekturbeschreibung als solches ist kein Selbstzweck und stiftet für sämtliche Stakeholder und zu unterschiedlichen Zeitpunkten im Systemlebenszyklus erheblichen Nutzen. Die ISO nennt hierfür zahlreiche Beispiele. Diese zeigen auch, warum die Architekturbeschreibung ein solch kritischer Punkt in einem Projekt ist. Die Architekturbeschreibung… Das Konzept der ISO 42010 erscheint zunächst sehr abstrakt. Wenn man sich allerdings ein wenig mit ihrer Darstellungsform und Intention beschäftigt, erkennt man, dass die ISO wirklich ein hervorragendes Gerüst ist, um die Zusammenarbeit vieler Stakeholder, ihrer Aufgaben und Darstellungsweisen zu organisieren und verständlich zu machen. Im Kern müssen Entwicklungsorganisationen erkennen, dass eine Architekturbeschreibung zentraler Ausgangspunkt der Zusammenarbeit ist und dass es viele gültige Darstellungsformen gibt – nur müssen sie organisiert und klar strukturiert sein. Den richtigen Zugang bietet die ISO 42010. Weitere Normen im Systems Engineering Eine weitere Norm im Systems Engineering, die ISO 15288, beschäftigt sich mit dem System-Lebenszyklus-Prozess. Unsere Software iQUAVIS berücksichtigt beide Normen. Christian TschirnerSystems Engineering ist eine Lebensart – wer sie einmal kennt, kommt nicht von ihr los! Ich brenne dafür, das Engineering zu verändern. Weg von verwirrenden Lasten- und Pflichtenheften hin zu einer modellbasierten Spezifikation. Das hilft mir, viele Aufgaben eines Projekts besser zu bewältigen, mit Kollegen ein gemeinsames eindeutiges Systemverständnis zu bilden und immer die relevanten Aufgaben im Blick zu haben. Und außerdem: Ich bin überzeugt, dass innovative Geschäftsmodelle nur mit einem solchen Ansatz möglich werden: Smarte Services, Things that think, … Let’s go together! www.two-pillars.de/

Die ISO/IEC/IEEE 42010 – Software und Systems Engineering Weiterlesen »

iquavis 4.0 mbse software update

iQUAVIS 4.0 – unser MBSE Software-Update

Updates, iQUAVIS, News /

iQUAVIS 4.0 ist da! Wir freuen uns, Ihnen das neueste Update von iQUAVIS vorstellen zu dürfen! Das Werkzeug iQUAVIS hilft Ihnen, komplexe Entwicklungsprojekte mit Hilfe von Systems Engineering zu meistern. Mit seinen Komponenten Systemarchitektur und Projektmanagement verschafft Ihnen iQUAVIS den entscheidenden Wettbewerbsvorteil. In der neuen Version gibt es ein paar sehr schöne Neuerungen, die Ihnen die Arbeit noch mehr erleichtern. Ein paar davon stellen wir Ihnen in diesem Beitrag vor. Datenaustauschformate Mit der Version 4.0 wurden die Möglichkeiten zur Werkzeugkopplung gestärkt. Das geht nun sowohl über unsere REST API als auch über das Konzept der OSLC (Open Services for Lifecycle Collaboration). OSLC (Open Services for Lifecycle Collaboration) Es erfordert großen Aufwand, Daten, die redundant in mehren Dateien projektübergreifend verwendet werden, durch Kopieren und Einfügen zu synchronisieren. Ein solcher manueller Schritt kann leicht Fehler zur Folge haben und Daten verfälschen. Aus diesen Grund hat sich das modellbasierte Systems Engineering entwickelt, kurz MBSE. iQUAVIS hat auf Basis des OSLC Konzeptes nun die Möglichkeiten geschaffen, sich mit anderen Werkzeugen automatisch zu verbinden. REST API Die REST API wurde gestärkt. Neben generellen Verbesserungen ist auch die Anbindung von Werkzeugen des Requirement Managements im Fokus gewesen, s.d. nun beispielsweise die Round Trip-Fähigkeit über ReqIF Datenaustausch stark profitiert: Der Anwender kann vorhandene Daten aktualisieren oder löschen, wenn er Daten zwischen DOORS und iQUAVIS importiert oder exportiert. Bei diesem Vorgang können Benutzer wahlweise den Befehl „gekennzeichnete DOORS Daten löschen“ ausführen oder weglassen. Transparenz bei der Zusammenarbeit Wenn Sie im Team an einem gemeinsamen Datensatz arbeiten, ist es wichtig zu erfahren, was in Ihrer Abwesenheit passiert ist. Veränderte Daten können von iQUAVIS im Worksheet nun automatisch farblich hervorgehoben und mit Zeitstempel gekennzeichnet werden. So ersparen Sie sich zeitaufwändige Kontrollen. Außerdem besteht die Möglichkeit, alle Änderungen ab einem beliebigen Datum anzeigen zu lassen. Dazu müssen keine zusätzlichen Verlaufsdaten gespeichert werden. Neue Abhängigkeitstypen und Visualisierung Ein neuer Abhängigkeitstyp „Abhängigkeit (Beziehung)“ ergänzt die bestehende „Abhängigkeit (Hierarchie)“. Durch zwei unterschiedliche Arten von Abhängigkeiten erweitern sich Ihre Möglichkeiten zur Modellierung und Analyse von Modellen (z. B. Kostenanalyse, Marktauswirkungen, etc.). Die Abhängigkeitstypen können als Bedingungen zum Extrahieren von Informationen genutzt werden, z. B. in Filtern und Arbeitsblättern. Die Funktion „Baum erweitern“ ermöglicht das Verfolgen der „Abhängigkeit (Beziehung)“. Funktionslinien aus den Blockdefinitionsdiagrammen können nun zusätzlich auch im Baum angezeigt werden. Die Darstellung der Abhängigkeitsbeziehungen kann im Menü aktiviert werden. Veränderte Daten im Arbeitsblatt markieren In diesem kurzen Video geben wir einen Einblick in iQUAVIS und wie Sie veränderte Daten im Arbeitsblatt markieren können: Christian Dr. BremerDr. Christian Bremer ist Gründer und Geschäftsführer bei Two Pillars. Er verantwortet die Bereiche Entwicklung und IT, Administration und Personalwesen. Seit seiner Zeit beim Fraunhofer IEM beschäftigt sich Christian Bremer mit Model-Based Systems Engineering. Er berät und begleitet Unternehmen bei der Einführung. Dabei werden immer wieder auch neue Use-Cases und Feature in iQUAVIS implementiert. www.two-pillars.de/

iQUAVIS 4.0 – unser MBSE Software-Update Weiterlesen »

CONSENS Methode Titelbild

CONSENS Methode

MBSE /

Im Systems Engineering fällt häufig der Begriff „CONSENS Methode“. Doch was ist das eigentlich und warum ist diese Methode so wichtig im Systems Engineering? Diese Frage erörtere ich in diesem Artikel und gehe auf das Thema „Systemmodell“ und „Systemarchitektur“ ein. CONSENS – CONceptual design Specification technique for the Engineering of complex Systems ist eine Spezifikationstechnik für die fachdisziplinübergreifende Zusammenarbeit in der Entwicklung mechatronischer Systeme.

CONSENS Methode Weiterlesen »

Nach oben scrollen