Ellenőrzési bejelentkezés a lefedettségen túl

A hitelesítés aláírásának általános tervezési nézete az, hogy egy átfogó hitelesítési tervvel kell kezdeni, amely kiterjed a specifikációk és használati esetek, az építészeti definíció és minden egyéb vonatkozó dokumentum között meghatározott minden követelményre. Ezután teszteket dolgoznak ki, hogy lefedjék az ellenőrzési terv minden jellemzőjét. Ezeket a teszteket lefuttatják és hibakeresik, és az azonosított problémákat a tervezésen belül kezelik. Ez a folyamat addig ismétlődik, amíg a lefedettség el nem éri a megállapodás szerinti szintet. A funkcionális lefedettség az a mérőszám, amellyel ezt a folyamatot mérik, és jól működik a hatókörén belül. A főbb elektronikus tervezési automatizálási (EDA) gyártók olyan eszközökkel rendelkeznek, amelyek segítségével szimulációkat futtathatnak, lefedettségi statisztikákat halmozhatnak fel, és segítenek továbbfejleszteni ezeket a mutatókat. De ez nem az egész történet a signoffban. A lefedettség az ellenőrzési tervnek való megfelelést méri, ami több lépéssel távolodik az ügyfél követelményeitől. Honnan tudják a tervezők, hogy a kritikus információkat nem dobták el vagy nem adták hozzá az út során?

Mi számít még a bejelentkezéskor?

Minden, ami a belső fejlesztésű funkcionális specifikációk/követelmények előtt számít. Nem lehet teljesen lezárni a hurkot a vevői követelmények és a megvalósítás/ellenőrzés között, hacsak ezek nem szerepelnek az elemzésben. Mostanra az értékláncokat tömörítették, és a chipen alapuló rendszerek (SoC) egyre alkalmazás-specifikusabbak. A vásárlók pontosan az igényeikre hangolt terveket várnak el, ezért a megvalósítás/ellenőrzés során az általuk követelményként meghatározottakat össze kell hangolni. Nem lesz jó fogadtatás, ha az ügyfél felfedezi, hogy várhatóan az eltérések javítását végzi.

A kihívás itt az, hogy a definíció meglehetősen vegyes bemeneti készletből állhat: Word, PDF, DITA alapú dokumentumok, táblázatok, Simulink, SysML vagy virtuális modell prototípusok, valamint szoftverbetöltések, amelyeknek a végső hardveren futniuk kell (talán némi eltéréssel). változtatások). Dokumentált követelmények is lehetnek DOORS, Jama Connect vagy hasonló formátumban. Hogyan jelzi az ellenőrző csapat, a tervezőcsapat vagy az építész, hogy a megvalósítás és az ellenőrzés megfelel a követelményeknek? Természetesen minden tőlük telhetőt megtesznek, de hol van a részletes és auditálható folyamat annak biztosítására, hogy minden követelmény megfeleljen a megvalósítás megvalósításának, és hogy a megvalósítás ellenőrzése megfelelően lefedve legyen?

Hogy ezt konkrétabbá tegyük, tegyük fel, hogy van egy olyan funkció, amelyet egy fontos ügyfél szeretne, de senki más nem. Talán figyelmen kívül hagyás vagy félreértés miatt ez a funkció nem szerepel a funkcionális specifikációban/követelményben. Túl gyakran fordul elő. Ezt a problémát még a 100%-os lefedettség eszménye sem fogja megoldani, mivel a lefedettség csak annyira jó, mint az ellenőrzési terv. Nagy probléma, ha az ellenőrzési terv nem tükrözi pontosan a követelményeket.

Vagy tegyük fel, hogy a tervezés során egy csapat úgy dönt, hogy nem tudja pontosan azt megvalósítani, amit a specifikáció kér, hanem egy alternatívát valósítanak meg abban a hitben, hogy az ugyanolyan jó vagy még jobb lesz. A csapat nem tudja, hogy ez a változás néhány ritka, de fontos felhasználási esetben hatással lesz a teljesítményre. Lehet, hogy ezt elkapják a szimulációban? Talán, de nagyon nehéz átfogónak lenni a rendszerszintű tesztelésben. Fennáll annak a veszélye, hogy ez a problémás változás egészen a szilíciumig fennmarad.

A követelmények nyomon követése kiegészíti az ellenőrzés aláíró lefedettségét

A Word-dokumentumok, a virtuális modellek és a regiszter-átviteli szint (RTL) közötti ekvivalencia-ellenőrzés futtatása valószínűleg életünkben nem lehetséges, de nem is kell. A rendszerépítők és a szoftvercsapatok már aktívan használják a követelmények nyomon követését, mint egy nagyon robusztus módszert a legfelső szintű és a megvalósítási szintű követelmények közötti megfelelés nyomon követésére egészen a megvalósításig, az ellenőrzésig és a tesztelésig. Ezt a nyomon követhetőséget támogatja a követelmény-követés a Requirements Interchange Format (ReqIF) használatával olyan platformokkal, mint a DOORS és a Jama Connect eszközök.

Bár ezeket az eszközöket a szoftvervilágban való könnyű alkalmazásra tervezték, nem értik a hardver szemantikáját. Támogatják az „idegen objektum” kapcsolatokat a tervezési és ellenőrzési adatokhoz való kapcsolódáshoz, de az ilyen kapcsolatok helyes létrehozásának terhe a tervező és hitelesítő mérnökökre hárul. Ez talán nem is olyan rossz, ha csak néhány száz követendő objektum lenne. De gondolj a memóriatérképre, a megszakítási térképre, az IO keverési térképre; ezek több tízezer vagy több objektumra futhatnak. Mindezen objektumok manuális frissítése tervezési változtatásokkal és újraparticionálással rendkívül nehézzé, ha nem lehetetlenné válik.

Egy jobb megközelítés a nyomon követhetőség menedzsmentje, amely csatlakozhat olyan eszközökhöz, mint a ReqIF az ügyféloldalon, és közvetlenül a tervező és ellenőrző csapatok által nyomon követett műtermékekhez. A tervezési szemantika megértése lehetővé teszi a követelmények és a megvalósítás közötti összefüggések kikövetkeztetését, és ezek helyes követését a projekt fejlődése során. Ez a módszer auditálható kapcsolatokat biztosít az ügyfél specifikációitól kezdve a tervezési követelményeken át egészen a SoC megvalósításáig.

Ez a nyomon követhetőség, amely teljesítheti az ellenőrzés aláírási célját, és csekély hatással van az SoC tervezőcsapataira. Az a fajta nyomon követhetőségi támogatás, amelyet megtalál Arteris Harmony Trace.