CAST-15

Sammanfoga högnivå- och lågnivåkrav

FAA-publikation
Förkortning	CAST-15
Året började	2003
Organisation	Programvaruteam för certifieringsmyndigheter
Domän	Flygelektronik , typcertifiering

CAST-15 , sammanslagning av högnivå- och lågnivåkrav är ett positionsdokument för certifieringsmyndigheter Software Team ( CAST). Det är en FAA- publikation som "inte utgör officiell policy eller vägledning från någon av myndigheterna", utan tillhandahålls sökande för certifiering av mjukvara och hårdvara endast i utbildnings- och informationssyfte.

DO-178B/C definierar ett acceptabelt sätt för certifiering av luftvärdig programvara. Unikt introducerade DO-178B en distinktion mellan högnivåkrav och lågnivåkrav som formella produkter för analys och design av mjukvarukrav vid utveckling av luftvärdig programvara. Dessa två kravnivåer, som bevis på mjukvarans luftvärdighet, tilldelades distinkta mål av DO-17B/C. Men under snäva förhållanden tillåter den standardens vägledning en kombination av dessa två nivåer till en enda kravnivå, men varnar för praxis i allmänhet.

Detta positionsdokument handlar om observerat missbruk av denna vägledning; några sökande kombinerade högnivå- och lågnivåkrav för "enkla" produkter, men uppnådde inte alla relaterade mål.

Detta positionsdokument är också ett exempel på att certifieringsmyndigheter använder skillnaden mellan "vad" och "hur" mellan krav på hög och låg nivå som DO-178B/C inte tydligt förklarar.

Bakgrund

Olika intressenter för programvarudefinition och -verifiering har olika mål och abstraktionsnivåer. De intressenter som ansvarar för att definiera eller verifiera högnivåprogramvaruprodukters funktionalitet är i allmänhet oroade över strukturerna och beteendet hos produktens externa gränssnitt, och detaljer om interna mjukvarustrukturer stödjer inte nödvändigtvis detta fokus. Å andra sidan behöver de som är ansvariga för att definiera och verifiera kravtäckning för all intern kod mycket finare detaljer om interna mjukvarustrukturer. Detta är motiveringen för att DO-178B/C fastställer distinkta mål för krav på hög och låg nivå, med hänsyn till sökande som utvecklar ytterligare kravskikt på stora projekt.

DO-178B möjliggjorde dock möjligheten att utveckla endast en nivå av krav för särskilt enkla system. Det vill säga, certifieringsmyndigheter (t.ex. FAA-utsedda ingenjörsrepresentanter ) skulle inte förvänta sig fler eller färre kravlager än nödvändigt. Certifieringsmyndigheternas erfarenhet var dock att vissa sökande missbrukade eller missbrukade denna avsikt, och som ett resultat av detta upptäckte sådana sökande sent i sina projekt att de inte kunde visa att de efterlevde reglerna och var tvungna att upprepa vissa aktiviteter.

Detta är också ett problem för all användning av utvecklingsverktyg som potentiellt minskar upplösningen av krav i ett projekt, särskilt de som använder notationer av högre abstraktion (t.ex. UML eller blockflödesmodellering). Sökande som använder sådana verktyg förväntas i allmänhet deklarera om deras utvecklingsprocesser använder sådana verktygs notation rollen av att beskriva antingen högnivåkrav eller lågnivåkrav, men vanligtvis inte båda.

Status

I allmänhet har CAST Position Papers utfärdats för att harmonisera granskning av programvaruprojekt som genomförts enligt DO-178B eller DO-254. Men de var också avsedda att informera om utvecklingen och den eventuella releasen av DO-178C och stödjande publikationer. Eftersom mycket av diskussionen och logiken som registrerats i CASTerna inte ingår i de nyare publikationerna, förblir CASTerna en källa till insikt i de uppdaterade standarderna.

Detta CAST-15 Position Paper tillhandahålls inte längre på FAA:s publikationswebbplats eftersom teamets bekymmer togs upp av FAQ #81 i DO-248C , Supporting Information for DO-178C och DO-278A och genom ändringar och förtydliganden i releasen av DO -178 Revision C :

• Vanliga frågor har skapats av europeiska certifieringsmyndigheter som var oroade över risken för att sökande utvecklar ospårbara och overifierbara luckor i sina krav, och den rekommenderar inte att man slår ihop höga och låga kravnivåer till en enda nivå.
• Anteckningen "Den sökande kan behöva motivera processer för programvaruutveckling som ger en enda kravnivå." lades till i DO-178C avsnitt 5.0, sida 31.

Ingen av publikationerna innehåller dock helt den "fullständiga diskussionen om detta ämne" som är inspelad CAST-15.

Mycket av samma innehåll i det ursprungliga CAST-15 Position Paper publiceras i 2012 års EASA- certifieringsmemo EASA-CM-SWCEH-002 (avsnitt 23 sammanslagning av högnivå- och lågnivåkrav).

Innehåll

DO-178C/ DO-178B ger vägledning för att slå samman högnivå- och lågnivåprogramvarukrav. Nominellt, i DO-178C/DO-178B-sammanhang, är högnivåkraven för en certifierad mjukvaruprodukt skilda från lågnivåprogramvarukraven, de förra är utdata från mjukvarukravsprocessen och de senare är utdata från programvaran Designprocessen.

• Högnivåkrav är i huvudsak de systemkrav som är tilldelade programvaruprodukten (en utomstående bild av vad den fullständiga mjukvaruprodukten ska vara och göra).
• Lågnivåkrav är resultatet av nedbrytning och utarbetande av krav så att källkoden kan produceras, granskas och testas direkt från lågnivåkraven (en inifrånbild av hur mjukvaruprodukten ska implementeras för att göra det).

I vissa applikationer är system-/högnivåkraven tillräckligt enkel och detaljerad för att källkoden kan produceras och verifieras direkt. I den här situationen anses system-/högnivåkraven också vara lågnivåkrav, vilket innebär att, förutom att uppnå målen för högnivåkraven, samma krav också måste uppfylla målen för lågnivåkraven .

Oron som föranledde CAST-15 är att vissa sökande till programvarucertifiering tolkade ovanstående riktlinjer som att de tillåter att kombinera både högnivåprogramvarukrav och lågnivåprogramvarukrav i ett enda programvarukravdokument eller annan artefakt utan att ange vilka krav som är Högnivå och som är lågnivå, men utelämnar också spårbarhet mellan lågnivå- och högnivåkraven och försummar att identifiera härledda krav på återkoppling till systemprocesser, inklusive systemsäkerhet.

Det här ståndpunktsdokumentet diskuterar flera problem och faror som certifieringsmyndigheter ser till följd av sammanslagning av lågnivåkrav i samlingen av högnivåkrav, och rekommenderar att detta inte görs. Ersättningsinnehållet som publiceras i FAQ #81 i DO-248C Supporting Information för DO-178C och DO-278A ger en kortare lista över certifieringsproblem för att kombinera (eller slå samman) dessa två "vad"- och "hur"-nivåer till en enda uppsättning av krav utan att särskilja de relevanta certifieringsmålen för de två nivåerna. FAQ #81 rekommenderar också att man inte slår samman High-Level och Low-Levels även i fall där koden kan skrivas och verifieras i ett "enkla steg" av krav som den ursprungliga DO-178B/C-vägledningen tillåter, men ger förslag på hur att ta itu med bekymmer.

Modellbaserad utveckling

Skillnaden mellan, eller kombinationen av, högnivå- och lågnivåkrav är ett särskilt problem med modellbaserad utveckling . Eftersom leverantörer och sökande använder modellbaserade utvecklingsverktyg i utvecklingen av luftburen mjukvara, uppstår oro för automatisering och eliminering av nivåer av certifieringsbevis. Argument förs för noggrann beteckning av vilka modellbaserade artefakter som representerar högnivåkrav och vilka som representerar lågnivåkrav. Slutligen har standarden DO-331 (Model-Based Development and Verification), tillägg till DO-178C, förtydligat dessa aspekter och anger att krav på hög nivå är krav som ligger före den modell som modellen har utvecklats från, varvid lågnivåkraven är de som finns i själva modellen. DO-331 har klargjort frågan för modellbaserad utveckling, och nivåsammanslagningsproblemen i CAST-15 är inte tillämpliga på modellbaserad utveckling.

externa länkar

• CAST-15 på Wayback Machine (arkiverad 2017-08-29 . Hämtad 2021-12-03.