Hej alle. Jeg anvender ofte systemtekniske principper i mit arbejde og vil gerne dele denne tilgang med samfundet.
Systemteknik - uden standarder, men kort sagt, er det processen med at udvikle et system som ret abstrakte komponenter uden reference til specifikke enhedsprøver. Under denne proces etableres egenskaberne for systemkomponenterne og forbindelserne mellem dem. Derudover er det nødvendigt at gøre systemet konsistent og optimalt, og at systemet lever op til kravene. I denne tutorial vil jeg vise systemtekniske teknikker ved at bruge eksemplet med at designe et ret simpelt adgangskontrolsystem (ACS).
Danner den oprindelige arkitektur
Når et system, uanset hvad, lige begynder at blive udviklet, dukker rektangler med pile op i vores hoveder eller på papir. Sådanne rektangler er komponenter systemer. Og pilene er tilslutning mellem komponenter. Og meget ofte har vi ikke tid til at sidde og tænke på, hvordan alle de komponenter, vi har defineret, vil fungere sammen med hinanden, og i sidste ende begynder vi at skabe en masse krykker, der kommer med overflødige designs.
Det er vigtigt at huske, at fra systemets og dets arkitekturs synspunkt er en komponent en ret abstrakt ting. For eksempel, hvis vores system har en mikrocontroller, så er det på det arkitektoniske niveau kun vigtigt for os, at det er en mikrocontroller, og ikke at det er STM32, Arduino eller Milander. Desuden er det ofte slet ikke klart for os, hvad der præcist skal være i systemet, og vi henvender os til systemteknik for at udvikle krav til udstyr, software mv.
For vores eksempel med ACS vil vi forsøge at formulere dets formål. Dette vil hjælpe os med at identificere dets komponenter. Så adgangskontrolsystemets opgave er at tillade en begrænset kreds af mennesker ind i lokalet. Det vil sige, at det er en smart lås. Derfor har vi den første komponent - en slags enhed, der låser og låser døren op! Lad os ringe til ham Dørlås
Hvordan ved vi, at en person kan komme ind? Vi vil ikke sætte en vagt i fængsel og tjekke pas, vel? Lad os give folk specielle kort med RFID-tags, hvorpå vi vil registrere unikke ID'er eller andre data, der gør det muligt for os at identificere en person nøjagtigt. Så har vi brug for en enhed, der kan læse disse tags. Fantastisk, vi har en komponent mere, RFID-læser
Lad os se igen på, hvad vi fik. RFID-læser læser nogle data, gør adgangskontrolsystemet noget med det, og på baggrund af dette styres noget Dørlås. Lad os stille følgende spørgsmål - hvor skal man gemme listen over personer med adgangsrettigheder? Bedst i databasen. Derfor skal vores system kunne sende forespørgsler og behandle svar fra databasen. Så vi har en komponent mere - DBHandler. Så vi har modtaget en ekstremt abstrakt, men tilstrækkelig til at begynde med, beskrivelse af systemet. Vi forstår, hvad det skal gøre, og hvordan det virker.
I stedet for et stykke papir vil jeg bruge System Composer, et særligt værktøj til modellering af systemarkitekturer i Simulink-miljøet, og lave 3 komponenter. Ovenfor beskrev jeg forbindelserne mellem disse komponenter, så lad os straks forbinde dem:
Udvidelse af arkitekturen
Lad os se på vores diagram. Det ser ud til, at alt er fint, men i virkeligheden er det ikke. Se på dette system fra brugerens synspunkt - brugeren bringer kortet til læseren og...? Hvordan ved en bruger, om de får lov eller nægtet adgang? Det er nødvendigt på en eller anden måde at underrette ham om dette! Lad os derfor tilføje en komponent mere - brugermeddelelse, UserNotify:
Lad os nu gå ned til et lavere abstraktionsniveau. Lad os prøve at beskrive nogle komponenter lidt mere detaljeret. Lad os starte med komponenten RFID-læser. I vores system er denne komponent ansvarlig for at læse RFID-tagget. Dens output bør indeholde nogle data (UID, brugerdata...). Men vent, RFID er ligesom NFC primært hardware, ikke software! Derfor kan vi antage, at vi hver for sig har selve RFID-chippen, som transmitterer "rå" data til en form for præprocessor. Så vi har et abstrakt stykke hardware, der kan læse RFID-tags, og abstrakt software, der kan konvertere data til det format, vi har brug for. Lad os ringe til dem RFIDSensor и RFIDParser henholdsvis. Hvordan viser jeg dette i System Composer? Du kan fjerne en komponent RFID-læser og sæt to komponenter i stedet, men det er bedre ikke at gøre dette, ellers vil vi miste arkitekturens læsbarhed. Lad os i stedet gå ind i RFIDReader og tilføje 2 nye komponenter:
Godt, lad os nu gå videre til at underrette brugeren. Hvordan vil systemet give brugeren besked om, at han nægtes eller får adgang til lokalerne? En person opfatter lyde og noget, der blinker bedst. Derfor kan du udsende et bestemt lydsignal, så brugeren er opmærksom, og blinke LED'en. Lad os tilføje de relevante komponenter til UserNotify:
Vi har skabt arkitekturen i vores system, men der er noget galt med det. Hvad? Lad os se på forbindelsesnavnene. InBus и OutBus - ikke helt normale navne, der ville hjælpe udvikleren. De skal omdøbes:
Så vi så på, hvordan systemtekniske metoder anvendes i den groveste tilnærmelse. Spørgsmålet opstår: hvorfor overhovedet bruge dem? Systemet er primitivt, og det ser ud til, at det udførte arbejde er unødvendigt. Du kunne straks skrive kode, designe en database, skrive forespørgsler eller lodde. Problemet er, at hvis du ikke tænker systemet igennem og forstår, hvordan dets komponenter er forbundet med hinanden, så vil integrationen af systemkomponenter tage lang tid og være ret smertefuldt.
Den vigtigste takeaway fra denne del er:
Brugen af systemingeniørmetoder og arkitekturmodellering i systemudvikling giver mulighed for at reducere omkostningerne ved at integrere komponenter og forbedre kvaliteten af det udviklede system.
Kilde: www.habr.com