Design auf Systemebene. Teil 1. Von der Idee zum System

Hallo zusammen. Ich wende bei meiner Arbeit häufig Prinzipien der Systemtechnik an und möchte diesen Ansatz mit der Community teilen.

Systems Engineering – ohne Standards, aber einfach ausgedrückt ist es der Prozess der Entwicklung eines Systems als ziemlich abstrakte Komponenten, ohne Bezug auf bestimmte Gerätebeispiele. Dabei werden die Eigenschaften der Systemkomponenten und die Verbindungen zwischen ihnen ermittelt. Darüber hinaus ist es notwendig, das System konsistent und optimal zu gestalten und den Anforderungen gerecht zu werden. In diesem Tutorial zeige ich Systemtechniktechniken am Beispiel des Entwurfs eines relativ einfachen Zugangskontrollsystems (ACS).

Gestaltung der Ausgangsarchitektur

Wenn ein System, egal welches, gerade erst entwickelt wird, erscheinen Rechtecke mit Pfeilen in unseren Köpfen oder auf dem Papier. Solche Rechtecke sind Komponenten Systeme. Und die Pfeile sind Verbindungen zwischen Komponenten. Und sehr oft haben wir keine Zeit, darüber nachzudenken, wie alle von uns definierten Komponenten miteinander funktionieren, und am Ende fangen wir an, eine Reihe von Krücken zu entwerfen und überflüssige Designs zu entwerfen.

Es ist wichtig zu bedenken, dass eine Komponente aus Sicht des Systems und seiner Architektur eine eher abstrakte Sache ist. Wenn unser System beispielsweise über einen Mikrocontroller verfügt, dann ist uns auf der Architekturebene nur wichtig, dass es sich um einen Mikrocontroller handelt und nicht, dass es sich um STM32, Arduino oder Milander handelt. Darüber hinaus ist uns oft überhaupt nicht klar, was genau im System enthalten sein wird, und wir wenden uns an die Systemtechnik, um Anforderungen an Geräte, Software usw. zu entwickeln.

Für unser Beispiel mit ACS werden wir versuchen, seinen Zweck zu formulieren. Dies wird uns bei der Identifizierung seiner Komponenten helfen. Die Aufgabe des Zutrittskontrollsystems besteht also darin, einen begrenzten Personenkreis in den Raum zu lassen. Das heißt, es ist ein intelligentes Schloss. Folglich haben wir die erste Komponente – eine Art Gerät, das die Tür verriegelt und entriegelt! Rufen wir ihn an Türschloss

Woher wissen wir, dass eine Person hineinkommen kann? Wir wollen doch keinen Wachmann stellen und die Pässe kontrollieren, oder? Geben wir den Menschen spezielle Karten mit RFID-Tags, auf denen wir eindeutige Ausweise oder andere Daten aufzeichnen, die es uns ermöglichen, eine Person genau zu identifizieren. Dann benötigen wir ein Gerät, das diese Tags lesen kann. Großartig, wir haben noch eine weitere Komponente, RFID-Lesegerät

Schauen wir uns noch einmal an, was wir haben. RFID-Lesegerät liest einige Daten, das Zutrittskontrollsystem macht etwas damit und auf dieser Grundlage wird etwas kontrolliert Türschloss. Stellen wir uns die folgende Frage: Wo soll die Liste der Personen mit Zugriffsrechten gespeichert werden? Am besten in der Datenbank. Daher muss unser System in der Lage sein, Anfragen zu senden und Antworten aus der Datenbank zu verarbeiten. Wir haben also noch eine weitere Komponente – DBHandler. Wir haben also eine äußerst abstrakte, aber zunächst ausreichende Beschreibung des Systems erhalten. Wir verstehen, was es tun soll und wie es funktioniert.

Anstelle eines Blattes Papier werde ich System Composer, ein spezielles Tool zur Modellierung von Systemarchitekturen in der Simulink-Umgebung, verwenden und 3 Komponenten erstellen. Oben habe ich die Verbindungen zwischen diesen Komponenten beschrieben, also verbinden wir sie gleich:

Design auf Systemebene. Teil 1. Von der Idee zum System

Erweiterung der Architektur

Schauen wir uns unser Diagramm an. Es scheint, dass alles in Ordnung ist, aber in Wirklichkeit ist es nicht so. Betrachten Sie dieses System aus der Sicht des Benutzers – der Benutzer bringt die Karte zum Lesegerät und...? Woher weiß ein Benutzer, ob ihm der Zugriff gestattet oder verweigert wird? Es ist notwendig, ihn irgendwie darüber zu informieren! Deshalb fügen wir eine weitere Komponente hinzu – Benutzerbenachrichtigung, UserNotify:

Design auf Systemebene. Teil 1. Von der Idee zum System

Gehen wir nun auf eine niedrigere Abstraktionsebene zurück. Versuchen wir, einige Komponenten etwas detaillierter zu beschreiben. Beginnen wir mit der Komponente RFID-Lesegerät. In unserem System ist diese Komponente für das Auslesen des RFID-Tags zuständig. Die Ausgabe sollte einige Daten enthalten (UID, Benutzerdaten ...). Aber Moment, RFID ist wie NFC in erster Linie Hardware, keine Software! Daher können wir davon ausgehen, dass wir separat über den RFID-Chip selbst verfügen, der „Rohdaten“ an eine Art Präprozessor überträgt. Wir haben also eine abstrakte Hardware, die RFID-Tags lesen kann, und eine abstrakte Software, die Daten in das von uns benötigte Format konvertieren kann. Nennen wir sie RFIDSensor и RFIDParser jeweils. Wie zeige ich dies im System Composer an? Sie können eine Komponente entfernen RFID-Lesegerät und stattdessen zwei Komponenten einfügen, aber es ist besser, dies nicht zu tun, sonst verlieren wir die Lesbarkeit der Architektur. Gehen wir stattdessen in RFIDReader hinein und fügen zwei neue Komponenten hinzu:

Design auf Systemebene. Teil 1. Von der Idee zum System

Großartig, jetzt können wir mit der Benachrichtigung des Benutzers fortfahren. Wie benachrichtigt das System den Benutzer darüber, dass ihm der Zutritt zu den Räumlichkeiten verweigert oder gestattet wird? Eine Person nimmt Geräusche und etwas Blinkendes am besten wahr. Daher können Sie ein bestimmtes Tonsignal ausgeben, um den Benutzer aufmerksam zu machen, und die LED blinken lassen. Fügen wir die entsprechenden Komponenten hinzu UserNotify:

Design auf Systemebene. Teil 1. Von der Idee zum System

Wir haben die Architektur unseres Systems erstellt, aber etwas stimmt damit nicht. Was denn? Schauen wir uns die Verbindungsnamen an. Im Bus и OutBus - nicht ganz normale Namen, die dem Entwickler helfen würden. Sie müssen umbenannt werden:

Design auf Systemebene. Teil 1. Von der Idee zum System

Deshalb haben wir uns angeschaut, wie Methoden des Systems Engineering in grober Näherung angewendet werden. Es stellt sich die Frage: Warum sie überhaupt nutzen? Das System ist primitiv und es scheint, dass die geleistete Arbeit unnötig ist. Sie könnten sofort Code schreiben, eine Datenbank entwerfen, Abfragen schreiben oder löten. Das Problem besteht darin, dass die Integration der Systemkomponenten lange dauert und ziemlich schmerzhaft ist, wenn man das System nicht durchdenkt und nicht versteht, wie seine Komponenten miteinander verbunden sind.

Die wichtigste Erkenntnis aus diesem Teil ist:

Der Einsatz systemtechnischer Methoden und Architekturmodellierung in der Systementwicklung ermöglicht es, die Kosten für die Integration von Komponenten zu senken und die Qualität des entwickelten Systems zu verbessern.

Source: habr.com

Kommentar hinzufügen