Hårdvaruarkitekt

(I automations- och ingenjörsmiljöer omfattar hårdvaruingenjören eller arkitekten elektronikteknik och elektroteknik , med subspecialiteter i analoga , digitala eller elektromekaniska system. )

Hårdvarusystemarkitekten eller hårdvaruarkitekten ansvarar för :

Gränssnitt med en systemarkitekt eller kunders intressenter . Det är utomordentligt sällsynt nuförtiden att tillräckligt stora och/eller komplexa hårdvarusystem som kräver en hårdvaruarkitekt inte kräver betydande mjukvara och en systemarkitekt. Hårdvaruarkitekten kommer därför normalt att ha ett gränssnitt med en systemarkitekt snarare än direkt med användare, sponsorer eller andra klientintressenter. Men i avsaknad av en systemarkitekt måste maskinvarusystemarkitekten vara beredd att gränssnitta direkt med klientens intressenter för att avgöra deras (utvecklande) behov som måste realiseras i hårdvara. Hårdvaruarkitekten kan också behöva gränssnitt direkt med en mjukvaruarkitekt eller ingenjör(er), eller med andra mekaniska eller elektriska ingenjörer.
Generera den högsta nivån av hårdvarukrav, baserat på användarens behov och andra begränsningar som kostnad och schema.
Säkerställa att denna uppsättning höga krav är konsekventa, fullständiga, korrekta och operativt definierade .
Utföra kostnads-nyttoanalyser för att bestämma de bästa metoderna eller tillvägagångssätten för att uppfylla hårdvarukraven; maximalt utnyttjande av kommersiella produkter från hyllan eller redan utvecklade komponenter.
Utveckla partitioneringsalgoritmer ( och andra processer) för att allokera alla nuvarande och förutsebara (hårdvaru)krav till diskreta hårdvarupartitioner så att ett minimum av kommunikation behövs mellan partitioner och mellan användaren och systemet.
Uppdelning av stora hårdvarusystem i (på varandra följande lager av) delsystem och komponenter som var och en kan hanteras av en enda hårdvaruingenjör eller team av ingenjörer.
Se till att en maximal robust hårdvaruarkitektur utvecklas.
Generera en uppsättning krav på acceptanstest , tillsammans med konstruktörerna, testingenjörerna och användaren, som avgör att alla hårdvarukrav på hög nivå har uppfyllts, särskilt för dator -mänskliga gränssnitt .
Generera produkter som skisser, modeller , en tidig användarmanual och prototyper för att hålla användaren och ingenjörerna ständigt uppdaterade och överens om systemet som ska tillhandahållas när det utvecklas.

Bakgrund

Stora systemarkitektur utvecklades som ett sätt att hantera system som är för stora för en person att föreställa sig, än mindre design. System av den här storleken håller snabbt på att bli normen, så arkitektoniska tillvägagångssätt och arkitekter behövs alltmer för att lösa problemen med stora system.

Användare och sponsorer

Ingenjörer som grupp har inte rykte om sig att förstå och svara på mänskliga behov bekvämt eller för att utveckla mänskligt funktionella och estetiskt tilltalande produkter. Arkitekter förväntas förstå mänskliga behov och utveckla mänskligt funktionella och estetiskt tilltalande produkter. En bra arkitekt är en översättare mellan användaren/sponsorn och ingenjörerna – och till och med bland bara ingenjörer av olika specialiteter. En bra arkitekt är också den främsta ägaren av användarens vision av slutprodukten – och av processen att härleda krav från och implementera den visionen.

Att bestämma vad användarna/sponsorerna faktiskt vill, snarare än vad de säger att de vill ha, är inte ingenjörskonst – det är en konst. En arkitekt följer inte en exakt procedur. Han/hon kommunicerar med användare/sponsorer på ett mycket interaktivt sätt – tillsammans extraherar de de verkliga kraven som krävs för det konstruerade systemet. Hårdvaruarkitekten måste ständigt förbli i kommunikation med slutanvändarna (eller en systemarkitekt). Därför måste arkitekten vara insatt i användarens miljö och problem. Ingenjören behöver bara vara mycket kunnig om det potentiella tekniska utrymmet.

Krav på hög nivå

Användaren/sponsorn bör se arkitekten som användarens representant och ge all input genom arkitekten. Direkt interaktion med projektingenjörer avråds generellt eftersom risken för ömsesidiga missförstånd är mycket stor. Användarkravsspecifikationen bör vara en gemensam produkt av användaren och hårdvaruarkitekten (eller system- och hårdvaruarkitekterna): användaren tar med sina behov och önskelista, arkitekten ger kunskap om vad som sannolikt kommer att visa sig genomförbart inom kostnad och tid begränsningar. När användarens behov översätts till en uppsättning höga krav är också den bästa tiden att skriva den första versionen av acceptanstestet, som därefter religiöst bör hållas uppdaterad med kraven. På så sätt kommer användaren att vara helt klar över vad han/hon får. Det är också ett skydd mot otestbara krav, missförstånd och kravkrypningar.

Utvecklingen av den första nivån av hårdvarutekniska krav är inte en ren analytisk övning och bör också involvera både hårdvaruarkitekten och ingenjören. Om några kompromisser ska göras – för att möta begränsningar som kostnad, schema, kraft eller utrymme, måste arkitekten se till att slutprodukten och det övergripande utseendet och känslan inte avviker särskilt långt från användarens avsikter. Ingenjören bör fokusera på att utveckla en design som optimerar begränsningarna men säkerställer en fungerande och pålitlig produkt. Arkitekten ägnar sig i första hand åt produktens komfort och användbarhet ; ingenjören är i första hand angelägen om produktens producerbarhet och användbarhet .

Tillhandahållandet av nödvändiga tjänster till användaren är den verkliga funktionen av ett konstruerat system. Men i takt med att systemen blir allt större och mer komplexa, och när deras tyngdpunkt flyttas bort från enkla hårdvarukomponenter, visar sig den snäva tillämpningen av traditionella hårdvaruutvecklingsprinciper vara otillräcklig – tillämpningen av de mer allmänna principerna för hårdvaruarkitektur för design av (under)system anses behövas. En hårdvaruarkitektur är också en förenklad modell av den färdiga slutprodukten - dess primära funktion är att definiera hårdvarukomponenterna och deras relationer till varandra så att helheten kan ses som en konsekvent, fullständig och korrekt representation av vad användaren hade i åtanke – särskilt för dator-mänskliga gränssnitt. Den används också för att säkerställa att komponenterna passar ihop och relaterar på önskat sätt.

Det är nödvändigt att skilja mellan arkitekturen i användarens värld och den konstruerade hårdvaruarkitekturen. Den förra representerar och adresserar problem och lösningar i användarens värld. Det fångas huvudsakligen i dator-mänskliga gränssnitt (CHI) i det konstruerade systemet. Det konstruerade systemet representerar de tekniska lösningarna – hur ingenjören föreslår att utveckla och/eller välja och kombinera komponenterna i den tekniska infrastrukturen för att stödja CHI. I frånvaro av en arkitekt finns det en olycklig tendens att blanda ihop de två arkitekturerna, eftersom ingenjören tänker i termer av hårdvara, men användaren kanske tänker i termer av att lösa ett problem med att få människor från punkt A till punkt B i en rimlig tid och med rimlig energiförbrukning, eller för att få nödvändig information till kunder och personal. En hårdvaruarkitekt förväntas kombinera kunskap om både arkitekturen i användarens värld och om (alla potentiellt användbara) hårdvarutekniska arkitekturer. Den förra är en gemensam aktivitet med användaren; det senare är en gemensam aktivitet med ingenjörerna. Produkten är en uppsättning krav på hög nivå som återspeglar användarens krav som kan användas av ingenjörerna för att utveckla krav för design av hårdvarusystem.

Eftersom kraven utvecklas under loppet av ett projekt, särskilt ett långt, behövs en arkitekt tills hårdvarusystemet accepteras av användaren: arkitekten är den bästa försäkringen för att inga ändringar och tolkningar som görs under utvecklingens gång äventyrar användarens synvinkel .

Kostnads-nyttoanalyser

De flesta hårdvaruingenjörer är specialister. De känner till tillämpningarna för hårdvarudesign och utveckling på nära håll, tillämpar sin kunskap i praktiska situationer – det vill säga löser verkliga problem, utvärderar kostnadsfördelarna med olika lösningar inom sin hårdvaruspecialitet och säkerställer korrekt funktion av vad de än designar. Hårdvaruarkitekter är generalister. De förväntas inte vara experter på någon hårdvaruteknik eller tillvägagångssätt, men förväntas vara kunniga om många och kunna bedöma deras tillämplighet i specifika situationer. De tillämpar också sina kunskaper i praktiska situationer, men utvärderar kostnaden/nyttan av olika lösningar med olika hårdvaruteknologier, till exempel specialutvecklade kontra kommersiellt tillgängliga hårdvarukomponenter, och försäkrar att systemet som helhet fungerar enligt användarens förväntningar.

Många kommersiella eller redan utvecklade hårdvarukomponenter kan väljas oberoende enligt begränsningar som kostnad, respons, genomströmning etc. I vissa fall kan arkitekten redan montera slutsystemet utan hjälp. Eller så kan han/hon fortfarande behöva hjälp av en hårdvaruingenjör för att välja komponenter och för att designa och bygga någon funktion för speciella ändamål. Arkitekterna (eller ingenjörerna) kan också ta hjälp av specialister – inom säkerhet, säkerhet, kommunikation, hårdvara för speciella ändamål, grafik, mänskliga faktorer, test och utvärdering, kvalitetskontroll, RMA, gränssnittshantering etc. Ett effektivt hårdvaruarkitekturteam måste ha omedelbar tillgång till specialister inom kritiska specialiteter.

Avdelning och skiktning

En arkitekt som planerar en byggnad arbetar med den övergripande designen och ser till att den blir tilltalande och användbar för dess invånare. Medan det kan räcka med en ensam arkitekt för att bygga ett enfamiljshus, kan det dessutom behövas många ingenjörer för att lösa de detaljproblem som uppstår när ett nytt höghus ritas. Om jobbet är tillräckligt stort och komplext kan delar av arkitekturen utformas som komponenter. Det vill säga, om vi bygger ett bostadskomplex kan vi ha en arkitekt för komplexet, och en för varje typ av byggnad, som en del av ett arkitektteam.

Stora hårdvarusystem kräver också en arkitekt och mycket ingenjörstalang. Om det konstruerade systemet är stort och tillräckligt komplext, kan chefsarkitekten för hårdvarusystem skjuta upp till underordnade arkitekter för delar av jobbet, även om de alla kan vara medlemmar i ett gemensamt arkitektteam. Men arkitekten får aldrig ses som en ingenjörshandledare.

Arkitekten bör underallokera hårdvarukraven till huvudkomponenter eller delsystem som är inom ramen för en enskild hårdvaruingenjör, eller ingenjörschef eller underordnad arkitekt. I idealfallet är varje sådan hårdvarukomponent/delsystem ett tillräckligt fristående objekt för att det kan testas som en komplett komponent, separat från helheten, med endast en enkel testbädd för att leverera simulerade ingångar och registrera utgångar. Det vill säga, det är inte nödvändigt att veta hur ett flygledningssystem fungerar för att designa och bygga ett datahanteringsundersystem för det. Det är bara nödvändigt att känna till de begränsningar under vilka delsystemet förväntas fungera.

En bra arkitekt säkerställer att systemet, hur komplext det än är, bygger på relativt enkla och "rena" koncept för varje (under)system eller lager – lätt att förstå för alla, särskilt användaren, utan särskild utbildning. Arkitekten kommer att använda ett minimum av regler för att säkerställa att varje partition är väldefinierad och ren från smuts , omvägningar , genvägar eller förvirrande detaljer och undantag. Allt eftersom användarnas behov utvecklas (när systemet väl är i bruk och används), är det mycket lättare att senare utveckla ett enkelt koncept än ett som är laddat med undantag, specialfall och mycket "finstilt".

Lagring av hårdvaruarkitekturen är viktigt för att hålla det tillräckligt enkelt vid varje lager så att det förblir begripligt för en enda sinne. När skikten stiger upp blir hela system i lägre skikt enkla komponenter i de högre skikten, och kan försvinna helt och hållet i de högsta skikten.

Acceptanstest

Acceptansprovet förblir alltid arkitektens/arkitekternas huvudansvar. Det är det främsta sättet för arkitekten att bevisa för användaren att hårdvaran är som ursprungligen planerad och att alla underordnade arkitekter och ingenjörer har uppfyllt sina mål. Stora projekt tenderar att vara dynamiska, med förändringar längs vägen som behövs av användaren (t.ex. när hans problem förändras) eller förväntas av användaren (t.ex. av kostnads- eller schemaskäl). Men acceptanstest måste hållas aktuella hela tiden. De är det huvudsakliga sättet att hålla användaren informerad om hur den slutliga produkten kommer att fungera. Och de fungerar som det huvudsakliga målet som all underordnad personal måste designa, bygga och testa för.

Bra kommunikation med användare och ingenjörer

En byggnadsarkitekt använder skisser, modeller, ritningar. En maskinvarusystemarkitekt bör använda skisser, modeller och prototyper för att diskutera olika lösningar och resultat med användaren eller systemarkitekten, ingenjörer och underordnade arkitekter. Ett tidigt utkast till användarmanualen är ovärderligt, särskilt i samband med en prototyp. En uppsättning (tekniska) krav som ett sätt att kommunicera med användarna ska uttryckligen undvikas. En välskriven uppsättning krav, eller specifikation , är förståelig endast för ingenjörsbröderskapet, ungefär som ett juridiskt kontrakt är för advokater.

människor

Ört Sutter

Se även