Dag Allemaal. Ik pas in mijn werk vaak principes van systeemtechniek toe en wil deze aanpak graag met de gemeenschap delen.
Systeemengineering - zonder standaarden, maar simpel gezegd: het is het proces van het ontwikkelen van een systeem als tamelijk abstracte componenten, zonder verwijzing naar specifieke apparaatvoorbeelden. Tijdens dit proces worden de eigenschappen van de systeemcomponenten en de verbindingen daartussen vastgesteld. Daarnaast is het noodzakelijk om het systeem consistent en optimaal te maken en dat het systeem voldoet aan de eisen. In deze tutorial zal ik technieken voor systeemtechniek laten zien aan de hand van het voorbeeld van het ontwerpen van een vrij eenvoudig toegangscontrolesysteem (ACS).
Het vormen van de initiële architectuur
Wanneer een systeem, wat er ook gebeurt, net begint te worden ontwikkeld, verschijnen er rechthoeken met pijlen in ons hoofd of op papier. Dergelijke rechthoeken zijn dat wel componenten systemen. En de pijlen zijn dat verbinding tussen componenten. En heel vaak hebben we geen tijd om na te denken over hoe alle componenten die we hebben gedefinieerd met elkaar zullen werken, en uiteindelijk beginnen we een aantal krukken te maken en komen we met overtollige ontwerpen.
Het is belangrijk om te onthouden dat vanuit het oogpunt van het systeem en zijn architectuur een component een tamelijk abstract iets is. Als ons systeem bijvoorbeeld een microcontroller heeft, dan is het op architectonisch niveau voor ons alleen belangrijk dat het een microcontroller is, en niet dat het STM32, Arduino of Milander is. Bovendien is het voor ons vaak helemaal niet duidelijk wat er precies in het systeem zal zitten, en wenden we ons tot systems engineering om vereisten te ontwikkelen voor apparatuur, software, enz.
Voor ons voorbeeld met ACS zullen we proberen het doel ervan te formuleren. Dit zal ons helpen bij het identificeren van de componenten ervan. De taak van het toegangscontrolesysteem is dus om een beperkte kring mensen de kamer binnen te laten. Dat wil zeggen, het is een slim slot. Daarom hebben we het eerste onderdeel: een soort apparaat dat de deur vergrendelt en ontgrendelt! Laten we hem bellen Deurslot
Hoe weten we dat iemand naar binnen kan? We willen toch geen wachter aanstellen om paspoorten te controleren? Laten we mensen speciale kaarten geven met RFID-tags, waarop we unieke ID's of andere gegevens registreren waarmee we een persoon nauwkeurig kunnen identificeren. Dan hebben we een apparaat nodig dat deze tags kan lezen. Geweldig, we hebben nog een onderdeel, RFID-lezer
Laten we nog eens kijken naar wat we hebben. RFID-lezer leest wat gegevens, het toegangscontrolesysteem doet er iets mee, en op basis daarvan wordt er iets gecontroleerd Deurslot. Laten we de volgende vraag stellen: waar kunnen we de lijst met mensen met toegangsrechten opslaan? Beste in database. Daarom moet ons systeem verzoeken kunnen verzenden en antwoorden uit de database kunnen verwerken. We hebben dus nog een onderdeel - DBHandler. We hebben dus een uiterst abstracte, maar om te beginnen voldoende, beschrijving van het systeem ontvangen. Wij begrijpen wat het moet doen en hoe het werkt.
In plaats van een stuk papier zal ik System Composer gebruiken, een speciaal hulpmiddel voor het modelleren van systeemarchitecturen in de Simulink-omgeving, en 3 componenten maken. Hierboven heb ik de verbindingen tussen deze componenten beschreven, dus laten we ze meteen met elkaar verbinden:
Het uitbreiden van de architectuur
Laten we naar ons diagram kijken. Het lijkt erop dat alles in orde is, maar in werkelijkheid is dat niet zo. Bekijk dit systeem vanuit het standpunt van de gebruiker: de gebruiker brengt de kaart naar de lezer en...? Hoe weet een gebruiker of hem of haar toegang wordt verleend of geweigerd? Het is noodzakelijk om hem hiervan op de een of andere manier op de hoogte te stellen! Laten we daarom nog een component toevoegen: gebruikersmelding, GebruikerNotificeren:
Laten we nu naar een lager abstractieniveau gaan. Laten we proberen enkele componenten wat gedetailleerder te beschrijven. Laten we beginnen met het onderdeel RFID-lezer. In ons systeem is dit onderdeel verantwoordelijk voor het uitlezen van de RFID-tag. De uitvoer ervan moet enkele gegevens bevatten (UID, gebruikersgegevens...). Maar wacht, RFID is, net als NFC, in de eerste plaats hardware, geen software! Daarom kunnen we ervan uitgaan dat we afzonderlijk de RFID-chip zelf hebben, die ‘ruwe’ gegevens naar een soort preprocessor verzendt. We hebben dus een abstract stukje hardware dat RFID-tags kan lezen, en abstracte software die gegevens kan omzetten in het formaat dat we nodig hebben. Laten we ze bellen RFID-sensor и RFIDParser respectievelijk. Hoe kan ik dit weergeven in System Composer? U kunt een onderdeel verwijderen RFID-lezer en in plaats daarvan twee componenten plaatsen, maar het is beter om dit niet te doen, anders verliezen we de leesbaarheid van de architectuur. Laten we in plaats daarvan naar RFIDReader gaan en twee nieuwe componenten toevoegen:
Geweldig, laten we nu verder gaan met het informeren van de gebruiker. Hoe informeert het systeem de gebruiker dat hem de toegang tot het pand wordt ontzegd of toegestaan? Een persoon neemt geluiden en iets dat knippert het beste waar. Daarom kunt u een bepaald geluidssignaal afgeven zodat de gebruiker oplet en de LED laat knipperen. Laten we de juiste componenten toevoegen GebruikerNotificeren:
We hebben de architectuur van ons systeem gecreëerd, maar er is iets mis mee. Wat? Laten we eens kijken naar de verbindingsnamen. InBus и UitBus - niet helemaal normale namen die de ontwikkelaar zouden helpen. Ze moeten worden hernoemd:
Daarom hebben we gekeken naar hoe systeemtechnische methoden in de meest ruwe benadering worden toegepast. De vraag rijst: waarom zou je ze überhaupt gebruiken? Het systeem is primitief en het lijkt erop dat het verrichte werk onnodig is. Je kunt meteen code schrijven, een database ontwerpen, queries schrijven of solderen. Het probleem is dat als je niet door het systeem nadenkt en niet begrijpt hoe de componenten met elkaar verbonden zijn, de integratie van systeemcomponenten lang zal duren en behoorlijk pijnlijk zal zijn.
De belangrijkste conclusie uit dit deel is:
Het gebruik van systems engineering-methoden en architectuurmodellering bij systeemontwikkeling maakt het mogelijk de kosten van het integreren van componenten te verlagen en de kwaliteit van het ontwikkelde systeem te verbeteren.
Bron: www.habr.com