Rendszertervezés

A rendszertervezési technikákat összetett projektekben alkalmazzák: nyomtatott áramköri tervezés, robotika, hídépítés, szoftverintegráció és űrhajó tervezés. A rendszertervezés számos eszközt használ, amelyek magukban foglalják a modellezést és szimulációt, a követelmények elemzését és az ütemezést a komplexitás kezelésére.

A rendszertervezés egy olyan multidiszciplináris mérnöki és mérnöki menedzsment terület, amely a komplex rendszerek tervezésére, integrálására és életciklusuk alatti kezelésére összpontosít. Alapvetően a rendszertechnika a rendszergondolkodás elveit alkalmazza ezen ismeretanyag megszervezésére. Az ilyen erőfeszítések egyéni eredménye, az "tervezett rendszer", amely úgy definiálható, mint olyan komponensek kombinációja, amelyek szinergiában működnek együtt, hogy hasznos funkciót lássanak el.

Az olyan kérdések, mint a követelménytervezés, megbízhatóság, logisztika, különböző csapatok koordinálása, tesztelés és értékelés, karbantarthatóság és sok más tudományterület, "ilitásoknak" szokás nevezni, amelyek elengedhetetlenek a sikeres rendszertervezéshez, fejlesztéshez, megvalósításhoz és végső leszereléshez,mert mindezek nélkül a nagy vagy összetett projektek egyre nehezebbé vállnak. A rendszertervezés az ilyen projektek munkafolyamataival, optimalizálási módszereivel és kockázatkezelési eszközeivel foglalkozik. Technikai és emberközpontú tudományterületeket fed át, mint például az ipari mérnökség, a termelési rendszermérnökség, a folyamatmérnökség, a gépészmérnökség, a gyártásmérnökség, a termelésmérnökség, az irányítástechnika, a szoftverfejlesztés, az elektrotechnika, a kibernetika, a repüléstechnika, a szervezetelmélet, az építőmérnökség és a projektmenedzsment. A rendszertervezés biztosítja, hogy egy projekt vagy rendszer minden lehetséges aspektusát figyelembe vegyék és integrálják egy egésszé.

A rendszertervezési folyamat egy felfedezési folyamat, amely teljesen eltér a gyártási folyamattól. A gyártási folyamat az ismétlődő tevékenységekre összpontosít, amelyek minimális költséggel és idővel kiváló minőségű eredményeket érnek el. A rendszertervezési folyamatnak a megoldásra váró valós problémák feltárásával és a legvalószínűbb vagy a legnagyobb hatással előforduló hibák azonosításával kell kezdődnie. A rendszertervezés magában foglalja a megoldások keresését ezekre a problémákra.

Története

QFD minőségi ház vállalati termékfejlesztési folyamatokhoz

A rendszertervezés kifejezés az 1940-es évek Bell Telephone Laboratories-ig vezethető vissza.[1] Az a szükséglet, hogy egy rendszer egészének tulajdonságait azonosítsák és kezeljék, amelyek összetett mérnöki projektek esetében jelentősen eltérhetnek az alkotóelemek tulajdonságainak összegétől, különböző iparágakat, különösen az Egyesült Államok hadserege számára rendszereket fejlesztő ágazatokat ösztönözte a rendszertervezés alkalmazására.[2][3]

Amikor már nem volt lehetséges a rendszer fejlesztésének evolúciójára támaszkodni, és a meglévő eszközök nem voltak elegendőek a növekvő igények kielégítésére, új módszereket kezdtek kidolgozni, amelyek közvetlenül kezelték a bonyolultságot.[4] A rendszertechnika folyamatos fejlődése új módszerek és modellezési technikák kifejlesztését és azonosítását foglalja magában. Ezek a módszerek elősegítik a tervezési rendszerek tervezésének és fejlesztési irányításának jobb megértését, ahogy azok egyre összetettebbé válnak. Az ebben az időszakban kifejlesztett népszerű eszközök, amelyeket gyakran használnak a rendszertechnika területén, közé tartoznak: az USL, UML, QFD és IDEF .

1990-ben számos amerikai vállalat és szervezet képviselői megalapították a rendszermérnöki szakmai társaságot, a National Council on Systems Engineering-et (NCOSE). Az NCOSE azért jött létre, hogy kielégítse a rendszermérnöki gyakorlatok és az oktatás fejlesztésének szükségességét. Az Egyesült Államokon kívüli rendszermérnökök növekvő részvételének eredményeként a szervezet nevét 1995-ben Nemzetközi Rendszertervezés Tanácsra (INCOSE) változtatták. Számos országban kínálnak rendszermérnöki posztgraduális programokat, és a továbbképzési lehetőségek gyakorló mérnökök számára is elérhető.

Koncepció

Néhány meghatározás
Simon Ramo, akit egyesek a modern rendszertervezés megalapítójának tartanak, a következőképpen határozta meg ezt a tudományágat: "...a mérnöki ág, amely az egésznek a részektől elkülönülő tervezésére és alkalmazására koncentrál, és egy problémát keres a saját részeiben. a teljesség, figyelembe véve az összes oldalt és minden változót, és összekapcsolva a társadalmit a technológiaival."[5] – Conquering Complexity, 2005.
"Interdiszciplináris megközelítés és eszközök a sikeres rendszerek megvalósításához"[6] – INCOSE kézikönyv, 2004.
"A rendszertervezés a rendszerek tervezésének, létrehozásának és üzemeltetésének robusztus megközelítése. Egyszerűen fogalmazva, a megközelítés a rendszercélok azonosításából és számszerűsítéséből, alternatív rendszertervezési koncepciók létrehozásából, a tervezési szakmák elvégzéséből, a rendszer kiválasztásából és megvalósításából áll. legjobb tervezés, annak ellenőrzése, hogy a terv megfelelően van-e megépítve és integrálva, valamint a megvalósítás utáni értékelés arról, hogy a rendszer mennyire teljesíti (vagy teljesítette) a célokat."[7] – NASA Systems Engineering Handbook, 1995.
"A hatékony rendszerek létrehozásának művészete és tudománya, teljes rendszer, egész élet elveit használva" VAGY "Az összetett kérdésekre és problémákra optimális megoldási rendszerek létrehozásának művészete és tudománya"[8] – Derek Hitchins, a rendszermérnöki professzor, korábbi elnök INCOSE (Egyesült Királyság), 2007.
"A koncepció a mérnöki oldalról a mérnök tudós evolúciója (azaz a tudományos generalista, aki tág szemléletet tart fenn). A módszer a csapatszemléletű. A nagy léptékű rendszerproblémáknál tudósokból és mérnökökből álló csapatok, generalisták A szakemberek és a szakemberek is közös erőfeszítéseket tesznek a megoldás megtalálásában és fizikai megvalósításában... A technikát más néven rendszerszemléletűnek vagy csapatfejlesztési módszernek nevezték."[9] – Harry H. Goode és Robert E. Machol, 1957.
"A rendszertervezési módszer felismeri, hogy minden rendszer egy integrált egész, még akkor is, ha változatos, speciális struktúrákból és részfunkciókból áll. Továbbá elismeri, hogy minden rendszernek számos célja van, és hogy a köztük lévő egyensúly rendszerenként nagyon eltérő lehet. A módszerek arra törekszenek, hogy a súlyozott céloknak megfelelően optimalizálják a rendszer általános működését, és elérjék a részeinek maximális kompatibilitását."[10] – Harold Chestnut Systems Engineering Tools, 1965.

A rendszertervezés nem csupán egy megközelítést jelent, hanem újabban egy mérnöki tudományágat is. A rendszertechnikai oktatás célja, hogy különböző megközelítéseket formálisan rögzítsen, és ezzel új módszereket és kutatási lehetőségeket azonosítson, hasonlóan más mérnöki területeken tapasztaltakhoz. Megközelítésként a rendszertechnika holisztikus és interdiszciplináris jellegű.

Eredet és hagyományos hatókör

A mérnöki tudomány hagyományos hatóköre magában foglalja a fizikai rendszerek megtervezését, kialakítását, fejlesztését, gyártását és üzemeltetését. Az eredetileg elképzelt rendszertechnika ebbe a hatókörbe tartozik. A "rendszertechnika" ebben az értelemben a mérnöki fogalmak kidolgozására utal.

Eredet és hagyományos terjedelem

A "rendszertervezés" kifejezés használata idővel kibővült és magában foglalja a "rendszerek" szélesebb, holisztikusabb fogalmát és a mérnöki folyamatokat. Ennek a meghatározásnak az evolúciója folyamatos vitatéma volt[11] és a kifejezés továbbra is a szűkebb és tágabb körre vonatkozik.

A hagyományos rendszertervezést az klasszikus értelemben vett mérnöki ágnak tekintették, azaz kizárólag fizikai rendszerekre alkalmazták, például űrhajókra és repülőgépekre. Az utóbbi időben a rendszertechnika kibővült, hogy tágabb értelmet nyerjen, különösen akkor amikor az embereket egy rendszer lényeges komponensének tekintették. Peter Checkland például úgy ragadja meg a rendszertervezés tágabb jelentését, hogy kijelenti, hogy a „mérnökség” „általános értelmében értelmezhető; megtervezhet egy találkozót vagy egy politikai megállapodást”.[12] :10

A rendszertechnika tágabb értelmezésével összhangban a Systems Engineering Body of Knowledge (SEBoK)[13] három típusú rendszertechnikát határoz meg:

  • A Product Systems Engineering (PSE) a hagyományos rendszertervezés, amely hardverből és szoftverből álló fizikai rendszerek tervezésére összpontosít.
  • Az Enterprise Systems Engineering (ESE) a vállalkozások, azaz szervezetek vagy szervezetek kombinációi rendszerként való felfogására vonatkozik.
  • A Service Systems Engineering (SSE) a szolgáltatási rendszerek tervezésével kapcsolatos. A Checkland a szolgáltatási rendszert olyan rendszerként határozza meg, amely egy másik rendszert szolgál ki.[12] A legtöbb civil infrastruktúra szolgáltató rendszer.

Holisztikus nézet

A rendszertechnika arra összpontosít, hogy az ügyfél igényeit és szükséges funkcionalitását már a fejlesztési ciklus kezdeti szakaszában elemzi és kinyeri, dokumentálja a követelményeket, majd tervezési szintézist és rendszerellenőrzést végez, miközben figyelembe veszi a teljes problémát, a rendszer életciklusát. Ez magában foglalja az összes érintett érdekelt teljes megértését is. Oliver és társai azt állítják, hogy a rendszertechnikai folyamat szétbontható:

  • A rendszermérnöki műszaki folyamat
  • A rendszermérnöki menedzsment folyamat

Oliver modellje szerint a Menedzsment Folyamat célja a technikai erőfeszítés szervezése az életciklus során, míg a Technikai Folyamat magában foglalja az elérhető információk értékelését, hatékonysági mutatók meghatározását, viselkedési modell létrehozását, szerkezeti modell létrehozását, trade-off elemzés végrehajtását és szekvenciális építési és tesztelési terv létrehozását.[14]

Az alkalmazástól függően, bár az iparban több modellt is használnak, mindegyik célja az említett különböző szakaszok közötti kapcsolatok azonosítása és a visszacsatolás beépítése. Ilyen modellek például a Vízesés modell és a VEE modell (más néven V modell).[15]

Interdiszciplináris terület

A rendszerfejlesztés gyakran különféle műszaki tudományágak közreműködését igényli.[16] Azáltal, hogy rendszerszemléletű ( holisztikus ) képet ad a fejlesztési erőfeszítésekről, a rendszertervezés segít az összes műszaki közreműködőt egységes csapatmunkába önteni, strukturált fejlesztési folyamatot hozva létre, amely a koncepciótól a gyártáson át a működésig, és bizonyos esetekben a megszüntetésig és ártalmatlanításig tart. .Egy beszerzés során a holisztikus integratív diszciplína összekapcsolja a hozzájárulásokat és egyensúlyt teremt a költség, a menetrend és a teljesítmény között, miközben elfogadható szintű kockázatot tart fenn a tárgy teljes életciklusában.[17]

Ez a szemlélet gyakran visszaköszön az oktatási programokban is, mivel a rendszertechnika kurzusokat más mérnöki tanszékek oktatói tartják, ami segít létrehozni egy interdiszciplináris környezetet.[18][19]

A komplexitás kezelése

A rendszertechnika iránti szükség a rendszerek és projektek növekvő bonyolultságával együtt nőtt, ez pedig exponenciálisan növelte az alkatrészeken belüli súrlódás lehetőségét, és ezzel együtt a tervezés megbízhatatlanságát. Amikor ebben a kontextusban beszélünk, a bonyolultság nemcsak a technikai rendszereket foglalja magában, hanem az adatok logikus emberi szervezettségét is. Ugyanakkor egy rendszer bonyolultabbá válhat a méret növekedése, valamint az adatok, változók vagy tervezésben részt vevő területek számának növekedése miatt. A Nemzetközi Űrállomás egy példa egy ilyen rendszerre.

A Nemzetközi Űrállomás egy nagyon összetett rendszer példája, amely rendszertervezést igényel.

Az intelligensebb vezérlőalgoritmusok fejlesztése, a mikroprocesszor-tervezés és a környezeti rendszerek elemzése szintén a rendszertervezés hatáskörébe tartozik. A rendszertechnika ösztönzi a eszközök és módszerek használatát a rendszerek bonyolultságának jobb megértésére és kezelésére. Néhány példa ezek közül a következő linkeken látható:[20]

A technikai rendszerek interdiszciplináris megközelítése eleve összetett, mivel a rendszerelemek viselkedése és kölcsönhatása nem mindig pontosan meghatározott vagy érthető. Az rendszertechnika egyik célja az ilyen rendszerek és alrendszerek meghatározása és jellemzése, valamint azok közötti kölcsönhatások. Ezzel sikeresen áthidalható a felhasználók, üzemeltetők, marketingszervezetek informális követelményei és a műszaki előírások között fennálló szakadék.

Evolúció szélesebb körben

A rendszermérnöki tevékenység köre

[21]

A rendszertervezés alapelvei – holizmus, kialakuló viselkedés, határ stb. – bármilyen rendszerre alkalmazható, legyen az összetett vagy egyéb, feltéve, hogy a rendszerszemléletet minden szinten alkalmazzák.[22] A védelem és űrkutatás mellett sok információ- és technológiával foglalkozó vállalat, szoftverfejlesztő cégek és az elektronika és kommunikáció területén működő iparágak is rendszermérnököket igényelnek csapatuk részeként.[23]

Az INCOSE Systems Engineering Center of Excellence (SECOE) elemzése azt mutatja, hogy a rendszertervezésre fordított optimális erőfeszítés a projekt teljes erőfeszítésének körülbelül 15–20%-a.[24] Ugyanakkor a tanulmányok kimutatták, hogy a rendszertervezés alapvetően a költségek csökkenéséhez vezet egyéb előnyök mellett.[24] Azonban, egészen mostanáig nem végeztek mennyiségi felmérést nagyobb léptékű vizsgálatokra kiterjedően, amely számos iparágat ölelne fel. Ilyen tanulmányok jelenleg is zajlanak annak meghatározására, hogy milyen hatékony a rendszertervezés, és milyen előnyöket mérhetünk fel.[25][26]

A rendszertervezés ösztönzi a modellezés és szimuláció használatát annak érdekében, hogy validálja az előfeltevéseket vagy elméleteket a rendszerek és bennük zajló kölcsönhatások tekintetében.[27][28]

A lehetséges hibák korai észlelését lehetővé tevő módszerek alkalmazása, a biztonságmérnöki területen, integrálódik a tervezési folyamatba. Ugyanakkor azoknak a döntéseknek a következményei, amelyeket egy projekt kezdetén hoznak, és amelyek következményei nem világosak, hatalmas hatással lehetnek később a rendszer életében, és a modern rendszermérnök feladata ezeket a problémákat feltárni és kritikus döntéseket hozni. Egyetlen módszer sem garantálja, hogy a mai döntések továbbra is érvényesek maradnak, amikor a rendszer évekkel vagy évtizedekkel az első megalkotása után üzembe kerül. Vannak azonban olyan technikák, amelyek támogatják a rendszertervezés folyamatát. A példák közé tartozik a puha rendszerek módszertana, Jay Wright Forrester rendszerdinamikai módszere és az Unified Modeling Language (UML) – mindezt jelenleg vizsgálják, értékelik és fejlesztik a mérnöki döntési folyamat támogatására.

Oktatás

A rendszertervezési oktatás gyakran a szokásos mérnöki kurzusok kiegészítésének tekintendő[29] tükrözve az ipar hozzáállását, miszerint a mérnöki hallgatóknak alapvető háttérre van szükségük valamelyik hagyományos mérnöki területen (pl. repülőgép- és űrmérnöki, építőmérnöki, villamosmérnöki, gépészmérnöki)., gyártásmérnöki, ipari mérnöki, vegyészmérnöki ) – plusz gyakorlati, valóságos tapasztalatra van szükség ahhoz, hogy hatékonyak legyenek rendszermérnökökként. A kifejezetten rendszermérnöki témájú egyetemi alapképzési programok száma növekszik, de továbbra sem gyakoriak, az ilyen anyagokat tartalmazó diplomákat, ezeket leggyakrabban ipari mérnöki BS- ként mutatják be. Jellemzően programokat (önmagukban vagy interdiszciplináris tanulmányokkal kombinálva) a diplomás szinttől kezdődően kínálnak mind a tudományos, mind a szakmai pályákon, ami MS / MEng vagy Ph.D fokozat megszerzését eredményezi. / EngD fokozat.

Az INCOSE a Stevens Institute of Technology Rendszermérnöki Kutatóközpontjával együttműködve rendszeresen frissített jegyzéket tart fenn a megfelelően akkreditált intézmények világméretű tudományos programjairól.[30] 2017-ben több mint 140 egyetemet sorol fel Észak-Amerikában, amelyek több mint 400 alap- és posztgraduális rendszermérnöki programot kínálnak. A terület széles körű intézményinek elismerése, mint különálló aldiszciplína viszonylag újkeletű; ugyanezen kiadvány 2009-es kiadása mindössze 80 ilyen iskoláról és programról számolt be.

A rendszermérnöki képzés rendszerközpontúnak vagy tartományközpontúnak tekinthető:

  • A rendszerközpontú programok a rendszertervezést külön tudományágként kezelik, és a legtöbb kurzus tanítása a rendszermérnöki elvekre és gyakorlatra összpontosít.
  • A tartományközpontú programok olyan lehetőséget kínálnak a rendszertervezésre, amelyet a mérnöki tudomány egy másik fő területével együtt lehet gyakorolni.

Mindkét minta azon igyekszik, hogy olyan rendszermérnököt képezzen, aki képes az interdiszciplináris projektek felügyeletére, olyan mélységgel, amelyet a magjának számító mérnököktől elvárnak.[31]

Rendszermérnöki témák

A rendszertechnika eszközök olyan stratégiák, eljárások és technikák, amelyek segítenek a rendszertechnikai tevékenységek végrehajtásában egy projekt vagy termék esetén. Ezeknek az eszközöknek a célja különböző, lehet adatbázis-kezelés, grafikus böngészés, szimuláció és következtetés, dokumentumkészítés, semleges import/export, és így tovább.[32]

Rendszer

A rendszermérnöki területen sokféle meghatározás létezik arról, hogy mi is az egy rendszer. Az alábbiakban néhány tekintélyes definíció található:

  • ANSI / EIA -632-1999: "A végtermékek összessége, amelyek lehetővé teszik a termékek adott cél elérését."[33]
  • DAU Systems Engineering Fundamentals: "emberek, termékek és folyamatok integrált összetétele, amely képes kielégíteni egy meghatározott igényt vagy célkitűzést."[34]
  • IEEE Std 1220-1998: "Olyan elemek és folyamatok halmaza vagy elrendezése, amelyek kapcsolatban állnak egymással, és amelyek viselkedése kielégíti a vásárlói/működési igényeket, és biztosítja a termékek életciklusának fenntartását."[35]
  • INCOSE Systems Engineering Handbook: "homogén entitás, amely előre meghatározott viselkedést mutat a valós világban, és heterogén részekből áll, amelyek külön-külön nem mutatják ezt a viselkedést, valamint összetevők és/vagy alrendszerek integrált konfigurációjából."[36]
  • INCOSE : "A rendszer különböző elemek konstrukciója vagy gyűjteménye, amelyek együttesen olyan eredményeket hoznak létre, amelyeket az elemek önmagukban nem érhetnek el. Az elemek vagy részek magukban foglalhatnak embereket, hardvert, szoftvert, létesítményeket, irányelveket és dokumentumokat; azaz minden dolgot rendszerszintű eredmények előállításához szükséges Az eredmények rendszerszintű minőségeket, tulajdonságokat, jellemzőket, funkciókat, viselkedést és teljesítményt tartalmaznak a részek közötti kapcsolat, vagyis hogyan kapcsolódnak egymáshoz."[37]
  • ISO/IEC 15288:2008: "Egy vagy több meghatározott cél elérése érdekében szervezett kölcsönhatásban lévő elemek kombinációja."[38]
  • NASA Systems Engineering Handbook: "(1) Azok az elemek kombinációja, amelyek együtt működnek a szükségletek kielégítésére alkalmas képesség létrehozása érdekében. Az elemek magukban foglalják az ehhez a célra szükséges összes hardvert, szoftvert, felszerelést, létesítményt, személyzetet, folyamatokat és eljárásokat. (2) ) A végtermék (amely működési funkciókat lát el) és lehetővé tevő termékek (amelyek életciklus-támogatási szolgáltatásokat nyújtanak a működő végtermékeknek), amelyek egy rendszert alkotnak."[39]

Rendszermérnöki folyamatok

A rendszertechnikai folyamatok magukban foglalják az összes kreatív, kézi és technikai tevékenységet, amelyek szükségesek a termék meghatározásához, és amelyeket el kell végezni a rendszerdefiníció kellően részletes rendszertervezési specifikációvá alakítása érdekében a termék gyártása és telepítése során. Egy rendszer tervezése és fejlesztése négy szakaszra osztható, mindegyik más-más meghatározással:[40]

  • Feladat definíció (informatív meghatározás)
  • Fogalmi szakasz (bíboros meghatározás)
  • Tervezési szakasz (formatív meghatározás)
  • Megvalósítási szakasz (a gyártás meghatározása)

Az alkalmazástól függően az eszközöket különböző szakaszokban használják a rendszertechnikai folyamatban:[21]

Modellek használata

A modellek fontos és sokféle szerepet játszanak a rendszertechnikában. Egy modellt többféleképpen is meghatározhatunk, például:[41]

  • A valóság absztrakciója, amely a való világgal kapcsolatos konkrét kérdések megválaszolására szolgál
  • Valós folyamat vagy struktúra utánzata, analógja vagy ábrázolása; vagy
  • Fogalmi, matematikai vagy fizikai eszköz a döntéshozó segítésére.

Ezek a definíciók elég széles körűek ahhoz, hogy magukban foglalják a rendszertervezés ellenőrzésében használt fizikai mérnöki modelleket, valamint olyan sémamodelleket, mint a funkcionális folyamatazonosítási diagram, és a kereskedelmi tanulmányok folyamatában használt matematikai (azaz mennyiségi) modelleket. Ez a szakasz az utóbbira összpontosít.[41]

A matematikai modellek és diagramok kereskedelmi tanulmányokban való használatának fő oka az, hogy ismert vagy becsülhető mennyiségekből származó becsléseket adjunk a rendszer hatékonyságáról, teljesítményéről vagy műszaki jellemzőiről, valamint a költségekről. Általában egy sor különálló modellre van szükség, hogy ezeket az eredményváltozókat biztosítsák. A matematikai modellek lényege egy számokban kifejezhető, értelmes kvantitatív kapcsolatrendszer a bemenetek és kimenetek között. Ezek az kapcsolatok lehetnek olyan egyszerűek, mint az alkotóelemek mennyiségeinek összeadása, hogy megkapjuk a teljes összeget, vagy olyan összetettek, mint egy differenciálegyenlet, amely leírja az űrhajó pályáját a gravitációs mezőben . Ideális esetben a kapcsolatok ok-okozati összefüggést fejeznek ki, nem csak korrelációt.[41] A sikeres rendszertervezési tevékenység kulcsa továbbá azok a módszerek is, amelyekkel ezeket a modelleket hatékonyan és eredményesen kezelik és használják a rendszerek szimulálására. Azonban a különböző területek gyakran ismétlődő modellezési és szimulációs problémákkal szembesülnek a rendszermérnöki területen, és az új fejlesztések célja az, hogy átörökítse a módszereket a különböző tudományos és mérnöki közösségek között, 'Modellezés és Szimuláció-alapú Rendszermérnökség' címmel.[42] [ oldal szükséges ]

Formalizmusok és grafikus ábrázolások modellezése

Kezdetben, amikor a rendszermérnök fő célja egy bonyolult probléma megértése, a rendszer funkcionális és adatkövetelményeinek kommunikálására grafikus ábrázolásokat használnak.[43] A közös grafikus ábrázolások közé tartoznak:

A grafikus ábrázolás összekapcsolja a rendszer különböző alrendszerét vagy részeit funkciók, adatok vagy interfészek révén. Az iparágtól függően bármelyik vagy mindegyik fent említett módszert használhatják az igényeknek megfelelően. Például az N2 diagram akkor alkalmazható, ha a rendszerek közötti interfészek fontosak. A tervezési fázis része a rendszer szerkezeti és viselkedési modelljeinek létrehozása.

Miután megértették a követelményeket, a rendszermérnök felelőssége azok finomítása és más mérnökökkel együtt a legjobb technológia meghatározása a feladathoz. Ebben a pontban a kereskedelmi tanulmányokkal kezdve a rendszertechnika súlyozott választások használatát ösztönzi a legjobb lehetőség meghatározására. Egy döntési mátrix, vagy Pugh módszer, az egyik módja (a QFD egy másik), hogy kiválasszák ezt a lehetőséget, miközben figyelembe veszik az összes fontos szempontot. A kereskedelmi tanulmány pedig tájékoztatja a tervezést, ami újra befolyásolja a rendszer grafikus ábrázolását (anélkül, hogy megváltoztatná a követelményeket). Egy SE folyamatban ez a szakasz az iteratív lépést jelenti, amelyet addig hajtanak végre, amíg megvalósítható megoldás nem található. Egy döntési mátrixot gyakran olyan technikákkal töltik fel, mint a statisztikai elemzés, megbízhatósági elemzés, rendszerdinamika (visszacsatolásos vezérlés) és optimalizálási módszerek.

Egyéb eszközök

Rendszermodellező nyelv

A Systems Modeling Language (SysML) egy modellezési nyelv, amelyet a rendszermérnöki alkalmazásokhoz használnak, és támogatja a széles körű bonyolult rendszerek specifikációját, elemzését, tervezését, ellenőrzését és validálását.[44]

Életciklus modellezési nyelv

A Lifecycle Modeling Language (LML) egy nyílt szabványú modellezési nyelv, amelyet a rendszermérnöki feladatokhoz terveztek, és támogatja az egész életciklust: a fogalmi, használati, támogatási és kivonási szakaszokat.[45]

Kapcsolódó mezők és almezők

Számos kapcsolódó terület szorosan összekapcsolódik a rendszermérnökhöz. A következő területek hozzájárultak a rendszermérnöki tudomány kialakulásához mint egy elkülönülő entitás:

Kognitív rendszerek tervezése

  A kognitív rendszerek tervezése (CSE) az ember-gép rendszerek vagy a szociotechnikai rendszerek leírásának és elemzésének sajátos megközelítése.[46] A CSE három fő témája az, hogy az emberek hogyan birkóznak meg a bonyolultsággal, hogyan valósul meg a munka az eszközök használatával, és hogyan írhatók le az ember-gép rendszerek és a szociotechnikai rendszerek mint közös kognitív rendszerek. A CSE azóta, hogy megjelent, elismert tudományággá vált, néha kognitív mérnökségnek is nevezik. A Közös Kognitív Rendszer (JCS) koncepciója különösen széles körben elterjedt módszerként szolgál annak megértésére, hogy a bonyolult szociotechnikai rendszerek hogyan írhatók le különböző felbontási szinteken. A több mint 20 éves tapasztalat a CSE terén széles körben leírásra került.[47][48]

Konfiguráció-menedzsment

Ahogyan a rendszermérnöki gyakorlat, a konfigurációkezelés is a védelmi és űrkutatási iparágakban egy átfogó, rendszer-szintű gyakorlat. A terület párhuzamosan halad a rendszermérnöki feladatokkal; ahol a rendszermérnöki feladatok a követelmények fejlesztését, azok kiosztását a fejlesztési elemekhez és a verifikációt foglalják magukban, addig a konfigurációkezelés a követelmények rögzítésével, visszakövethetőségével a fejlesztési elemhez és az elem auditálásával foglalkozik annak érdekében, hogy elérje a kívánt funkcionalitást, amelyet a rendszermérnöki és/vagy Teszt- és Verifikációs Mérnöki feladatok objektív tesztelésén keresztül bizonyítottak.

Irányítástechnika

A vezérléstechnika és a vezérlési rendszerek tervezése és megvalósítása, amely széles körben alkalmazott szinte minden iparágban, a rendszermérnöki egyik nagy alterülete. Egy autó sebességszabályzója és egy ballisztikus rakéta irányítórendszere két példa erre. A vezérlési rendszerek elmélete egy aktív alkalmazott matematika területe, amely a megoldási terek vizsgálatát és új módszerek kidolgozását jelenti a vezérlési folyamat elemzésére.

Ipari mérnökség

Az ipari mérnöki tudományág azon mérnöki terület, amely az emberek, pénz, tudás, információ, eszköz, energia, anyag és folyamatok integrált rendszereinek fejlesztésével, javításával, bevezetésével és értékelésével foglalkozik. Az ipari mérnöki tudomány az ipari elemzés és szintézis, valamint a matematikai, fizikai és társadalomtudományok elveire és módszereire támaszkodik, együtt az ipari elemzés és tervezés elveivel és módszereivel, hogy meghatározza, előre jelezze és értékelje az ilyen rendszerekkel kapcsolatban nyert eredményeket.

Termelési Rendszerek Mérnöksége

A Termelési Rendszer Mérnöki (PSE) egy új, fejlődő mérnöki ágazat, melynek célja a termelési rendszerek alapvető elveinek feltárása és felhasználása az elemzéshez, folyamatos fejlesztéshez és tervezéshez.[49]

Interfész kialakítása

Az interfész tervezése és annak specifikációja arra irányul, hogy biztosítsa a rendszer részeinek összekapcsolódását. Az interfésztervezés magában foglalja azt is, hogy biztosítsa a rendszer interfészeit az új funkciók fogadására, ideértve a mechanikai, elektromos és logikai interfészeket, beleértve a fenntartott vezetékeket, csatlakozóhelyeket, parancskódokat és biteket a kommunikációs protokollokban. Ezt bővíthetőségnek nevezik. A humán-számítógép interakció (HCI) vagy az ember-gép interfész (HMI) az interfésztervezés másik aspektusa, és a modern rendszertervezés kritikus aspektusa. A helyi hálózatok és a nagy kiterjedésű hálózatok kommunikációs protokolljainak tervezése során a rendszermérnöki elveket alkalmazzák.

Mechatronikai tervezés

A mechatronikai tervezés a rendszermérnökihez hasonlóan egy multidiszciplináris mérnöki terület, amely dinamikus rendszermodellezést használ a kézzelfogható konstrukciók kifejezésére. Ebben az értelemben szinte megkülönböztethetetlen a Rendszermérnöktől, de ami elkülöníti, az a kisebb részletekre való összpontosítás a nagyobb általánosítások és kapcsolatok helyett. Így mindkét területet a projektjeik terjedelme különbözteti meg, nem pedig a gyakorlati módszereik metodológiája.

Operációkutatás

  Az operatív kutatás támogatja a rendszertervezést. A műveletkutatás röviden az egy folyamat optimalizálásával foglalkozik többféle korlátozás mellett.[50][51]

Teljesítménytechnika

A teljesítménytervezés azt a tudományterületet jelenti, amelynek célja, hogy egy rendszer teljesítménye megfeleljen a vevői elvárásoknak élete során. A teljesítményt általában azonosítjuk az adott művelet végrehajtási sebességével vagy a műveletek számának képességével egy adott időegység alatt. A teljesítmény leromolhat, ha a végrehajtásra váró műveleteket korlátozza a korlátozott rendszerkapacitás . Például egy csomagkapcsolt hálózat teljesítményét a végpontok közötti csomagtovábbítási késleltetés vagy az egy óra alatt váltott csomagok száma jellemzi. A nagy teljesítményű rendszerek tervezése analitikus vagy szimulációs modellezést alkalmaz, míg a nagy teljesítményű implementáció megvalósítása alapos teljesítményteszttel jár. A teljesítménytervezés eszközei és folyamatai nagymértékben támaszkodik a statisztikákra, a sor-elméletre és a valószínűség-elméletre .

Programmenedzsment és projektmenedzsment

A programmenedzsment (vagy programmenedzsment) sok hasonlósága van a rendszermérnökséggel, azonban szélesebb alapokra támaszkodik, mint a rendszermérnökség mérnöki vonatkozásai. A projektmenedzsment szorosan kapcsolódik mind a programmenedzsmenthez, mind a rendszermérnökséghez. Mindkettő magában foglalja az ütemezést, mint mérnöki támogató eszközt az interdiszciplináris aggodalmak értékeléséhez a kezelési folyamat során. Különösen a források, a teljesítményjellemzők és a kockázat közvetlen kapcsolata a feladat időtartamához vagy a feladatok közötti függőségi hivatkozásokhoz és a rendszer teljes életciklusára gyakorolt hatásokhoz a rendszermérnökség területe.

Javaslat tervezés

A pályázattervezés tudományos és matematikai elvek alkalmazása költséghatékony pályázat-fejlesztő rendszer tervezésére, megépítésére és működtetésére. Alapvetően a javaslatmérnökség a "rendszermérnöki folyamatot" használja a költséghatékony javaslat létrehozásához és a sikeres javaslat esélyeinek növeléséhez.

Megbízhatósági tervezés

A megbízhatósági mérnökség azt a tudományterületet jelenti, amelynek célja, hogy egy rendszer egész életciklusán keresztül megfeleljen a vevők megbízhatóságra vonatkozó elvárásainak (azaz ne okozzon gyakrabban hibát, mint amire számítanánk). A hibák előrejelzése mellett legalább annyira fontos a hibák megelőzése is. A megbízhatósági mérnökség minden rendszeraspektusra vonatkozik. Szorosan kapcsolódik a karbantarthatósághoz, elérhetőséghez (néhányan inkább RAMS-nak nevezik), és az integrált logisztikai támogatáshoz. A megbízhatósági mérnökség mindig kritikus komponense a biztonságmérnökségnek, mint például a hibamód és hatáselemzés (FMEA) és a veszélyes hibafák elemzése, valamint a biztonságmérnökségnek.

Kockázat kezelés

A kockázatkezelés, a kockázatértékelés és -kezelés gyakorlata a Rendszermérnökség egyik interdiszciplináris része. A fejlesztési, beszerzési vagy működési tevékenységek során a kockázat beépítése a költségek, ütemezés és teljesítményjellemzők közötti kompromisszumokba az iteratív komplex konfigurációkezelést igényli, amely magában foglalja a nyomon követhetőség és az értékelés kezelését az ütemezés és követelménykezelés során különböző területeken és a rendszer teljes életciklusában. Ez olyan interdiszciplináris technikai megközelítést igényel, amely a rendszermérnökség sajátja. A rendszermérnökség során a kockázatkezelés meghatározza, testre szabja, végrehajtja és figyelemmel kíséri a kockázatkezelés strukturált folyamatát, amely az összesített erőfeszítés részévé válik.[52]

Biztonságtechnika

A biztonságmérnöki technikákat nem szakértő mérnökök is alkalmazhatják a bonyolult rendszerek tervezése során, hogy minimalizálják a biztonságkritikus hibák valószínűségét. A "Rendszerbiztonság Mérnöki" funkció segít az "új tervezésekben lévő biztonsági veszélyek" azonosításában, és segíthet a (lehetőleg) kockázatos körülmények hatásainak "csökkentésében" olyan technikákkal, amelyeket nem lehet kialakítani a rendszerekből.

Biztonságtechnika

A biztonságtechnika egy olyan interdiszciplináris területnek tekinthető, amely integrálja a vezérlőrendszer-tervezés, a megbízhatóság, a biztonság és a rendszertervezés gyakorlati közösségét . Tartalmazhat ilyen részspecialitásokat is, mint például a rendszerhasználók, célpontok és mások hitelesítése: emberek, tárgyak és folyamatok.

Szoftverfejlesztés

A szoftvermérnökség kezdetétől fogva hozzájárult a modern rendszermérnöki gyakorlat formálásához. A nagy szoftverintenzív rendszerek bonyolultságának kezelésére használt technikák jelentős hatással voltak a rendszermérnöki eszközök, módszerek és folyamatok formálására és átalakítására.

Hivatkozások

  1. ↑ Schlager (1956. július 1.). „Systems engineering: key to modern development”. IRE Transactions EM-3 (3), 64–66. o. DOI:10.1109/IRET-EM.1956.5007383. (Hozzáférés: 2023. november 16.)  
  2. ↑ Hall, Arthur D.. A Methodology for Systems Engineering. Van Nostrand Reinhold (1962. június 14.). ISBN 978-0-442-03046-9 
  3. ↑ Umbrello (2021. április 5.). „Coupling Levels of Abstraction in Understanding Meaningful Human Control of Autonomous Weapons: A Two-Tiered Approach”. Ethics and Information Technology 23 (3), 455–464. o. DOI:10.1007/s10676-021-09588-w. ISSN 1572-8439.  
  4. ↑ Sage, Andrew Patrick. Systems Engineering. Wiley IEEE (1992. június 14.). ISBN 978-0-471-53639-0 
  5. ↑ Conquering Complexity: lessons for defence systems acquisition, The Defence Engineering Group. University College London (2005. június 14.) 
  6. ↑ Systems Engineering Handbook, version 2a. INCOSE (2004. június 14.) 
  7. ↑ NASA Systems Engineering Handbook. NASA. SP-610S (1995. június 14.) 
  8. ↑ Derek Hitchins. INCOSE UK. (Hozzáférés: 2007. június 2.)
  9. ↑ Goode, Harry H.. System Engineering: An Introduction to the Design of Large-scale Systems. McGraw-Hill, 8. o. (1957. június 14.) 
  10. ↑ Chestnut, Harold. Systems Engineering Tools. Wiley (1965. június 14.). ISBN 978-0-471-15448-8 
  11. ↑ (2004. március 1.) „The Case for Evolving Systems Engineering as a Field within Engineering Systems”. MIT Engineering Systems Symposium. 
  12. ↑ a b Checkland, Peter.szerk.: Pyster: Systems Thinking, Systems Practice. John Wiley & Sons (1999. június 14.) 
  13. ↑ Checkland, Peter.szerk.: Pyster: Systems Thinking, Systems Practice. John Wiley & Sons (1999. június 14.)  2012. Systems Engineering Body of Knowledge. 1.0 ed: Stephens Institute and the Naval Postgraduate School.
  14. ↑ Oliver, David W.. Engineering Complex Systems with Models and Objects. McGraw-Hill, 85–94. o. (1997. június 14.). ISBN 978-0-07-048188-6 
  15. ↑ The SE VEE. SEOR, George Mason University. [2007. október 18-i dátummal az eredetiből archiválva]. (Hozzáférés: 2007. május 26.)
  16. ↑ Ramo, Simon. The Systems Approach: Fresh Solutions to Complex Problems Through Combining Science and Practical Common Sense. Anaheim, California: KNI (1998. június 14.) 
  17. ↑ 4. Systems Engineering, Defense Acquisition Guidebook. Defense Acquisition University. Hozzáférés ideje: 2015. augusztus 12. 
  18. ↑ Systems Engineering Program at Cornell University. Cornell University. (Hozzáférés: 2007. május 25.)
  19. ↑ ESD Faculty and Teaching Staff. Engineering Systems Division, MIT. (Hozzáférés: 2007. május 25.)
  20. ↑ Core Courses, Systems Analysis – Architecture, Behavior and Optimization. Cornell University. (Hozzáférés: 2007. május 25.)
  21. ↑ a b Systems Engineering Fundamentals (angol nyelven). Defense Acquisition University Press, 2001. [2017. január 31-i dátummal az eredetiből archiválva].
  22. ↑ Adcock: Principles and Practices of Systems Engineering. INCOSE, UK. [2007. június 15-i dátummal az eredetiből archiválva]. (Hozzáférés: 2007. június 7.)
  23. ↑ Systems Engineering, Career Opportunities and Salary Information. George Mason University, 1994 [2007. szeptember 22-i dátummal az eredetiből archiválva]. (Hozzáférés: 2007. június 7.)
  24. ↑ a b Understanding the Value of Systems Engineering. [2007. június 15-i dátummal az eredetiből archiválva]. (Hozzáférés: 2007. június 7.)
  25. ↑ Elm: Surveying Systems Engineering Effectiveness. Carnegie Mellon University. [2007. június 15-i dátummal az eredetiből archiválva]. (Hozzáférés: 2023. március 16.)
  26. ↑ Systems Engineering Cost Estimation by Consensus. (Hozzáférés: 2007. június 7.)
  27. ↑ Sage (2001. június 14.). „Modeling and Simulation in Systems Engineering”. Simulation 76 (2), 90. o. [2007. október 21-i dátummal az eredetiből archiválva]. DOI:10.1177/003754970107600207. (Hozzáférés: 2007. június 2.)  
  28. ↑ Smith (1962. szeptember 1.). „Simulation in Systems Engineering”. IBM Systems Journal 1, 33–50. o, Kiadó: IBM Research. [2007. június 4-i dátummal az eredetiből archiválva]. DOI:10.1147/sj.11.0033. (Hozzáférés: 2023. március 16.)  
  29. ↑ Didactic Recommendations for Education in Systems Engineering. (Hozzáférés: 2007. június 7.)
  30. ↑ INCOSE/Academic Council: Worldwide Directory of SE and IE Academic Programs. [2018. december 26-i dátummal az eredetiből archiválva]. (Hozzáférés: 2019. február 4.)
  31. ↑ Perspectives of Systems Engineering Accreditation. INCOSE. [2007. június 15-i dátummal az eredetiből archiválva]. (Hozzáférés: 2007. június 7.)
  32. ↑ Steven Jenkins: A Future for Systems Engineering Tools. NASA. [2007. szeptember 26-i dátummal az eredetiből archiválva]. (Hozzáférés: 2007. június 10.)
  33. ↑ Processes for Engineering a System (angol nyelven). Electronic Industries Alliance, 1999. [2010. július 5-i dátummal az eredetiből archiválva]. (Hozzáférés: 2018. június 17.)
  34. ↑ Systems Engineering Fundamentals. OCW.MIT.edu, 2001. január 1.
  35. ↑ Standard for Application and Management of the Systems Engineering Process (angol nyelven). IEEE. [2009. augusztus 1-i dátummal az eredetiből archiválva].
  36. ↑ Systems Engineering Handbook. INCOSE, 2007. [2015. március 18-i dátummal az eredetiből archiválva]. (Hozzáférés: 2009. július 10.)
  37. ↑ A Consensus of the INCOSE Fellows. INCOSE, 2006. [2006. október 29-i dátummal az eredetiből archiválva]. (Hozzáférés: 2009. július 10.)
  38. ↑ Systems and software engineering - System life cycle processes, 2008. [2019. augusztus 6-i dátummal az eredetiből archiválva]. (Hozzáférés: 2009. július 10.)
  39. ↑ NASA Systems Engineering Handbook. NASA. NASA/SP-2007-6105 (2007. június 14.) 
  40. ↑ J. Lienig. Fundamentals of Electronic Systems Design. Springer International Publishing, 6–7. o.. DOI: 10.1007/978-3-319-55840-0 (2017. június 14.). ISBN 978-3-319-55839-4 
  41. ↑ a b c System Analysis and Modeling Issues - NASA Systems Engineering Handbook (angol nyelven) pp. 85, 1995. [2008. december 17-i dátummal az eredetiből archiválva].
  42. ↑ szerk.: Gianni: Modeling and Simulation-Based Systems Engineering Handbook, 1st, CRC Press (2014. december 4.). ISBN 9781466571457 
  43. ↑ Long: Relationships between Common Graphical Representations in System Engineering. VitechCorp, 2002 [2017. augusztus 13-i dátummal az eredetiből archiválva].
  44. ↑ OMG SysML Specification. SysML Open Source Specification Project. (Hozzáférés: 2007. július 3.)
  45. ↑ LML Specification. LML Steering Committee. [2014. május 6-i dátummal az eredetiből archiválva]. (Hozzáférés: 2014. június 5.)
  46. ↑ Hollnagel (1983). „Cognitive systems engineering: New wine in new bottles” (angol nyelven). International Journal of Man-Machine Studies 18 (6), 583–600. o. DOI:10.1016/S0020-7373(83)80034-0. (Hozzáférés: 2023. november 16.)  
  47. ↑ Hollnagel. Joint cognitive systems: The foundations of cognitive systems engineering (angol nyelven). Taylor & Francis. DOI: 10.1201/9781420038194 (2005). ISBN 9780429122224. Hozzáférés ideje: 2023. november 16. 
  48. ↑ Hollnagel. Joint cognitive systems: Patterns in cognitive systems engineering (angol nyelven). Taylor & Francis. DOI: 10.1201/9781420005684 (2006). ISBN 9780429127663. Hozzáférés ideje: 2023. november 16. 
  49. ↑ Li, Jingshan. Production Systems Engineering. DOI: 10.1007/978-0-387-75579-3 (2009. június 14.). ISBN 978-0-387-75578-6 
  50. ↑ Postrel: Operation Everything. The Bostom Globe, 2004. június 27. [2012. március 31-i dátummal az eredetiből archiválva]. (Hozzáférés: 2005. november 30.)
  51. ↑ Crissey: SHHHH... It's a Secret. sas com Magazine, 2004 [2005. szeptember 20-i dátummal az eredetiből archiválva]. (Hozzáférés: 2005. november 30.)
  52. ↑ Risk Management Toolkit. MITRE, SE Process Office. (Hozzáférés: 2016. szeptember 8.)

Fordítás

Ez a szócikk részben vagy egészben a Systems engineering című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

További irodalom

További információk