मॉड्यूल ara::fw — Firewall

Functional Cluster Firewall मैनिफ़ेस्ट के स्थिति-निर्भर नियम सेटों के अनुसार नेटवर्क पैकेटों को फ़िल्टर करता है और ब्लॉक किए गए पैकेटों को IdsM (EXP_PlatformDesign पृ. 92) को Security Events के रूप में रिपोर्ट करता है। एप्लिकेशन FirewallStateSwitchInterface::SwitchFirewallState के माध्यम से सक्रिय Firewall स्थिति का चयन करते हैं। यह विधि एक ara::core::Future<void> लौटाती है और kServiceNotAvailable या kInvalidStateDependentFirewall [AP_SWS_Fw_82008] जैसी त्रुटियों की रिपोर्ट करती है। स्थितियाँ कोई निश्चित सूची नहीं हैं, बल्कि प्रति मॉडल किए गए इंटरफ़ेस के लिए एक एन्यूमिरेशन के रूप में जनरेट की जाती हैं। इंटरफ़ेस के इंस्टेंस केवल स्थानांतरित (move) किए जा सकते हैं, कॉपी नहीं किए जा सकते।

अधिक ›

मॉड्यूल fw Adaptive Platform के डेमन-आधारित Functional Cluster Firewall को निर्दिष्ट करता है। इसका एप्लिकेशन API ऑपरेशन SwitchFirewallState() के साथ इंटरफ़ेस FirewallStateSwitchInterface है, जिसका उपयोग Adaptive Application करती है (EXP_SWArchitecture पृ. 126)। क्लस्टर के दो कार्य हैं: यह Firewall स्थिति को स्विच करता है और Intrusion Detection System Manager (EXP_SWArchitecture पृ. 197) को Security Events रिपोर्ट करता है।

संदर्भ आरेख: FC Firewall मैनिफ़ेस्ट कॉन्फ़िगरेशन, एप्लिकेशन की स्थिति विनिर्देश, ऑपरेटिंग सिस्टम में नियम अनुप्रयोग और IdsM को SEv रिपोर्टिंग को जोड़ता है। स्रोत: EXP_PlatformDesign पृ. 97, EXP_SWArchitecture पृ. 197

फ़िल्टरिंग स्थिति-निर्भर है। OEM ड्राइविंग, पार्किंग या डायग्नोस्टिक्स जैसी स्थितियों को परिभाषित करता है, और किसी पैकेट के लिए केवल सक्रिय स्थिति के नियम ही लागू होते हैं (EXP_PlatformDesign पृ. 92)। मैनिफ़ेस्ट में AdaptiveFirewallModuleInstantiation इसके लिए StateDependentFirewall तत्वों को बंडल करता है। इनमें से प्रत्येक में क्रमबद्ध नियम गुण, एक वैकल्पिक defaultAction और संबंधित स्थितियों के संदर्भ शामिल हैं (TPS_ManifestSpecification पृ. 679)। कोड में, स्थितियाँ ara::fw::states [AP_SWS_Fw_81001] में प्रति इंटरफ़ेस जनरेट किए गए एन्यूमिरेशन के रूप में दिखाई देती हैं।

एप्लिकेशन ara::core::InstanceSpecifier से इंटरफ़ेस ऑब्जेक्ट बनाता है। यह कंस्ट्रक्टर थ्रेड-सेफ़ है [AP_SWS_Fw_82002]। SwitchFirewallState noexcept है और एक ara::core::Future<void> [AP_SWS_Fw_82008] लौटाता है। आंतरिक रूप से, परिदृश्य के अनुसार क्लस्टर ऑपरेटिंग सिस्टम में प्रत्येक Firewall नियम को व्यक्तिगत रूप से लागू करता है (EXP_SWArchitecture पृ. 232)। इंस्टेंस कॉपी नहीं किए जा सकते, लेकिन स्थानांतरित किए जा सकते हैं। Move और डिस्ट्रक्टर थ्रेड-सेफ़ नहीं हैं [AP_SWS_Fw_82004] [AP_SWS_Fw_82006]।

अनुक्रम आरेख: स्थिति परिवर्तन का अनुरोध एक Future के रूप में वापस आता है। इस बीच, प्रत्येक नियम को व्यक्तिगत रूप से लागू किया जाता है। स्रोत: EXP_SWArchitecture पृ. 232, [AP_SWS_Fw_82008]

त्रुटि की स्थिति में Future में FwErrc::kServiceNotAvailable या FwErrc::kInvalidStateDependentFirewall शामिल होता है [AP_SWS_Fw_83001]। अर्थ केवल नामों से ही निकाला जा सकता है: सेवा संभवतः उपलब्ध नहीं है, या लक्ष्य स्थिति के लिए एक मान्य नियम कॉन्फ़िगरेशन का अभाव है। प्रश्न Q-45e3225696efb3dc (खुला) FwErrorDomain::ThrowAsException के माध्यम से एक त्रुटि को FwException [AP_SWS_Fw_83012] के रूप में थ्रो किया जा सकता है। ब्लॉक किए गए पैकेट कोई API त्रुटि नहीं हैं। उन्हें IdsM को Security Events के रूप में रिपोर्ट किया जाता है, R23-11 में अतिरिक्त रूप से भिन्न प्रोटोकॉल के अनुसार विभेदित किया जाता है (SWS_Firewall पृ. 31)।

अधिक ›

एप्लिकेशन, ऑपरेटिंग सिस्टम और IdsM के बीच FC Firewall की भूमिका

मॉड्यूल fw Adaptive Platform के Functional Cluster Firewall का वर्णन करता है। यह डेमन-आधारित है और ऑपरेशन SwitchFirewallState() के साथ इंटरफ़ेस FirewallStateSwitchInterface को लागू करता है। एक Adaptive Application «use» संबंध के माध्यम से इस इंटरफ़ेस का उपयोग करती है (EXP_SWArchitecture पृ. 126)। उपयोग के मामले क्लस्टर को दो कार्यों तक सीमित करते हैं। “Switch Firewall State” को Adaptive Application द्वारा ट्रिगर किया जाता है, जिसमें ऑपरेटिंग सिस्टम सहयोग करता है। “Report Security Event” का लक्ष्य समान रूप से डेमन-आधारित Intrusion Detection System Manager (EXP_SWArchitecture पृ. 197) है।

आर्किटेक्चर अवलोकन कॉन्फ़िगरेशन, नियंत्रण और निष्पादन को एक-दूसरे से अलग करता है:

• Machine Manifest फ़िल्टर नियम प्रदान करता है।
• FC Firewall इसके साथ एक Firewall Engine को कॉन्फ़िगर करता है।
• एक OEM एप्लिकेशन Firewall स्थिति सेट करता है।
• क्लस्टर IdsM (EXP_PlatformDesign पृ. 97) को Security Events (SEvs) रिपोर्ट करता है।

प्राथमिकता में दो उपयोग के मामले हैं। पहला ड्राइविंग, पार्किंग या डायग्नोस्टिक सत्र जैसी OEM-विशिष्ट स्थितियों के साथ स्थिति-निर्भर फ़िल्टरिंग है। दूसरा ब्लॉक किए गए संदेशों के लिए Security Events के माध्यम से Intrusion Detection System का समर्थन करना है। क्वालिफ़िकेशन, SOC को अग्रेषण या परसिस्टेंट स्टोरेज को IdsM संभालता है (EXP_PlatformDesign पृ. 92)। मॉड्यूल का एकमात्र एप्लिकेशन API स्थिति परिवर्तन [AP_SWS_Fw_82008] है।

संदर्भ आरेख: FC Firewall Machine Manifest से कॉन्फ़िगरेशन और एप्लिकेशन से स्थिति विनिर्देश प्राप्त करता है। यह इंजन और ऑपरेटिंग सिस्टम को नियंत्रित करता है और IdsM को SEvs रिपोर्ट करता है। स्रोत: EXP_PlatformDesign पृ. 97, EXP_SWArchitecture पृ. 197, EXP_SWArchitecture पृ. 232

Firewall स्थितियाँ: मॉडल में स्टेट मशीन से जनरेट किए गए एन्यूमिरेशन तक

मैनिफ़ेस्ट मेटा-मॉडल में, FirewallStateSwitchInterface एक PortInterface को विशिष्ट बनाता है। firewallStateMachine भूमिका के माध्यम से, यह कितने भी (0..*) ModeDeclarationGroupPrototype तत्वों को एकत्रित करता है (TPS_ManifestSpecification पृ. 263)। व्यक्तिगत स्थितियाँ वैकल्पिक विशेषता value: PositiveInteger (TPS_ManifestSpecification पृ. 679) के साथ ModeDeclarations हैं।

प्रत्येक मॉडल किए गए इंटरफ़ेस के लिए, नेमस्पेस ara::fw::states में इससे एक अलग एन्यूमिरेशन enum class {<fwssi-sn>} : std::uint32_t जनरेट किया जाता है। इसे ara/fw/states/{<fwssi-sn>}.h [AP_SWS_Fw_81001] के माध्यम से शामिल किया जाता है। प्रत्येक मॉडल की गई Firewall स्थिति के लिए एक एन्यूमरेटर {<symbol-fw-state>} = {<fw-state-value>} [AP_SWS_Fw_81002] बनाया जाता है।

उपयोगकर्ताओं के लिए इसका अर्थ है: प्लेटफ़ॉर्म-व्यापी कोई निश्चित स्थिति सूची नहीं है। कौन सी स्थितियाँ मौजूद हैं, यह OEM मॉडल निर्धारित करता है (EXP_PlatformDesign पृ. 92)। SwitchFirewallState को EnumT प्रकार के पैरामीटर firewallState की आवश्यकता होती है [AP_SWS_Fw_82008]। व्याख्या: EnumT संबंधित इंटरफ़ेस के लिए जनरेट किए गए स्थिति एन्यूमिरेशन के अनुरूप होना चाहिए। प्रश्न Q-26dbe38f70cb0222 (खुला) इसके पक्ष में यह तथ्य है कि [AP_SWS_Fw_81001] स्पष्ट रूप से उन्हें “for FirewallStateSwitchInterface” स्थितियों के रूप में परिभाषित करता है।

संदर्भ आरेख (मॉडल–कोड): स्थितियाँ मॉडल में इंटरफ़ेस की स्टेट मशीन से आती हैं। प्रत्येक इंटरफ़ेस के लिए ara::fw::states में एक एन्यूमिरेशन जनरेट किया जाता है। स्रोत: TPS_ManifestSpecification पृ. 263, [AP_SWS_Fw_81001], [AP_SWS_Fw_81002], [AP_SWS_Fw_82008]

मैनिफ़ेस्ट कॉन्फ़िगरेशन: मॉड्यूल इंस्टेंस, स्थिति-निर्भर नियम सेट और पोर्ट मैपिंग

Firewall मॉड्यूल की मशीन-विशिष्ट सेटिंग्स AdaptiveFirewallModuleInstantiation में एकत्र की जाती हैं। संबंधित विनिर्देश R25-11 में DRAFT स्थिति रखता है (TPS_ManifestSpecification पृ. 677)। मॉड्यूल इंस्टेंस NonOsModuleInstantiation को विशिष्ट बनाता है और stateDepFirewall के माध्यम से कितने भी StateDependentFirewall तत्वों को संदर्भित करता है।

एक StateDependentFirewall में शामिल हैं:

• वैकल्पिक रूप से FirewallActionEnum प्रकार का एक defaultAction,
• क्रमबद्ध firewallRuleProps,
• firewallState (instanceRef) के माध्यम से उन ModeDeclarations के संदर्भ, जिनमें यह लागू होता है (TPS_ManifestSpecification पृ. 679)।

System Template संक्षेप में उनका वर्णन “Firewall rules that are defined in a firewall state” (TPS_SystemTemplate पृ. 644) के रूप में करता है।

नियम स्वयं bucketSize और refillAmount जैसी विशेषताओं वाले FirewallRule तत्व हैं। इसके अतिरिक्त मेटा-मॉडल NetworkLayerRule और TransportLayerRule को सूचीबद्ध करता है, बाद वाले में अन्य बातों के अलावा पोर्ट रेंज और checksumVerification शामिल हैं। एक CouplingElement भी firewallRule (TPS_ManifestSpecification पृ. 679) के माध्यम से नियमों को एकत्रित कर सकता है। विवरण के लिए System Template स्पष्ट रूप से मैनिफ़ेस्ट विनिर्देश (TPS_SystemTemplate पृ. 644) को संदर्भित करता है।

एप्लिकेशन के साथ कनेक्शन AdaptiveFirewallToPortPrototypeMapping द्वारा स्थापित किया जाता है। यह मॉड्यूल इंस्टेंस (संदर्भ firewall, 0..1) को एप्लिकेशन के RPortPrototype पर मैप करता है, जो स्टेट-स्विचिंग इंटरफ़ेस (TPS_ManifestSpecification पृ. 677) द्वारा टाइप किया गया है। दो प्रतिबंध लागू होते हैं:

• क्लास नोट इंटरफ़ेस को FirewallModeSwitchInterface कहता है, जबकि छवि शीर्षक और API इसे FirewallStateSwitchInterface कहते हैं। कोड के लिए [AP_SWS_Fw_82002] से प्राप्त नाम निर्णायक है।
• मैपिंग क्लास और उसके संदर्भ की स्थिति candidate (TPS_ManifestSpecification पृ. 677) है।

संदर्भ आरेख (मेटा-मॉडल): मॉड्यूल इंस्टेंस स्थिति-निर्भर नियम सेटों को बंडल करता है। मैपिंग उन्हें एप्लिकेशन के R-Port से जोड़ती है। स्रोत: TPS_ManifestSpecification पृ. 677, TPS_ManifestSpecification पृ. 679, TPS_ManifestSpecification पृ. 677

SwitchFirewallState के साथ स्थिति परिवर्तन का प्रवाह

कोड की तरफ़, एप्लिकेशन ara/fw/firewall_state.h को शामिल करता है। यह ara::core::InstanceSpecifier से स्पष्ट कंस्ट्रक्टर के माध्यम से ara::fw::FirewallStateSwitchInterface बनाता है। यह कंस्ट्रक्टर noexcept और थ्रेड-सेफ़ है [AP_SWS_Fw_82002]।

स्थिति परिवर्तन का अनुरोध SwitchFirewallState(EnumT firewallState) द्वारा किया जाता है। विधि noexcept है और एक ara::core::Future<void> लौटाती है। इसके लिए परिभाषित त्रुटियाँ FwErrc::kServiceNotAvailable और FwErrc::kInvalidStateDependentFirewall इसलिए Future के माध्यम से वापस आती हैं न कि अपवाद के रूप में [AP_SWS_Fw_82008]।

परिदृश्य “Switch Firewall State” तीन चरणों में आंतरिक प्रवाह को दिखाता है (EXP_SWArchitecture पृ. 232):

1. एप्लिकेशन FC Firewall पर SwitchFirewallState() को कॉल करता है।
2. क्लस्टर एक लूप “foreach FirewallRule” में ऑपरेटिंग सिस्टम पर प्रत्येक applyRule() को कॉल करता है।
3. लूप के बाद ही प्रतिक्रिया एप्लिकेशन पर वापस आती है।

applyRule() को वहाँ «aapInformative» के रूप में चिह्नित किया गया है। ऑपरेटिंग सिस्टम में नियमों को कैसे सक्रिय किया जाता है, यह पेलोड में प्लेटफ़ॉर्म-API के रूप में निर्दिष्ट नहीं है। R22-11 संस्करण ने इसी अनुक्रम को एक सफल परिदृश्य के रूप में दिखाया था (EXP_SWArchitecture पृ. 158)। बदलाव के बाद, केवल सक्रिय स्थिति के नियम ही जाँच और फ़िल्टर करते हैं (EXP_PlatformDesign पृ. 92)।

अनुक्रम आरेख (Sequence diagram): स्थिति परिवर्तन की सूचना Future के माध्यम से एसिंक्रोनस रूप से वापस दी जाती है। आंतरिक रूप से, क्लस्टर प्रत्येक नियम को व्यक्तिगत रूप से लागू करता है। स्रोत: EXP_SWArchitecture पृ. 232, [AP_SWS_Fw_82002], [AP_SWS_Fw_82008]

इंटरफ़ेस क्लास का लाइफ़टाइम, कॉपी और मूव नियम

FirewallStateSwitchInterface के विशेष फ़ंक्शन यह निर्धारित करते हैं कि इंस्टेंसेस को कैसे पास किया जा सकता है ([AP_SWS_Fw_82003] से [AP_SWS_Fw_82007]):

एलिमेंट	निर्धारण	धागे की सुरक्षा
InstanceSpecifier से कंस्ट्रक्टर	explicit, noexcept [AP_SWS_Fw_82002]	thread-safe
कॉपी कंस्ट्रक्टर / कॉपी असाइनमेंट	=delete [AP_SWS_Fw_82004] [AP_SWS_Fw_82005]	–
मूव कंस्ट्रक्टर / मूव असाइनमेंट	noexcept [AP_SWS_Fw_82006] [AP_SWS_Fw_82007]	not thread-safe
डिस्ट्रक्टर	noexcept [AP_SWS_Fw_82003]	not thread-safe

उपयोग के लिए इससे तीन नियम निकलते हैं:

• किसी इंस्टेंस को डुप्लिकेट नहीं किया जा सकता, बल्कि केवल मूव द्वारा ही आगे पास किया जा सकता है [AP_SWS_Fw_82004] [AP_SWS_Fw_82006]।
• एप्लिकेशन को मूव और विनाश (destruction) को समवर्ती एक्सेस (concurrent accesses) से स्वयं सुरक्षित करना होगा [AP_SWS_Fw_82003]।
• व्याख्या: मूव के बाद स्रोत ऑब्जेक्ट का उपयोग संभवतः SwitchFirewallState के लिए नहीं किया जाना चाहिए, क्योंकि आवश्यकताएँ केवल ट्रांसफ़र का वर्णन करती हैं, शेष बची स्थिति का नहीं [AP_SWS_Fw_82007]। प्रश्न Q-ccf0737ee5133103 (खुला)

स्वयं SwitchFirewallState की थ्रेड-सुरक्षा के बारे में आवश्यकता पाठ कोई जानकारी नहीं देता है [AP_SWS_Fw_82008]।

स्थिति आरेख (State diagram): एक इंस्टेंस InstanceSpecifier से बनता है, केवल मूव द्वारा स्थानांतरित किया जाता है और अंततः नष्ट कर दिया जाता है। स्रोत: [AP_SWS_Fw_82002], [AP_SWS_Fw_82003], [AP_SWS_Fw_82006], [AP_SWS_Fw_82007]

सक्रिय स्थिति में पैकेट फ़िल्टरिंग और Security Events की रिपोर्टिंग

फ़ायरवॉल नियमों को एक Firewall स्थिति को सौंपा जा सकता है। किसी पैकेट की जाँच के लिए केवल वर्तमान में सक्रिय स्थिति के नियमों का उपयोग किया जाता है (EXP_PlatformDesign पृ. 92)। प्रति स्थिति, StateDependentFirewall क्रमित नियम गुण और वैकल्पिक defaultAction प्रदान करता है (TPS_ManifestSpecification पृ. 679)।

SWS संस्करण R23-11 Security Events के असाइनमेंट का अधिक विस्तार से वर्णन करता है (SWS_Firewall पृ. 31):

• यदि कोई पैकेट किसी भी नियम से मेल नहीं खाता है, तो डिफ़ॉल्ट क्रिया लागू होती है।
• यदि डिफ़ॉल्ट क्रिया पैकेट को ब्लॉक करती है, तो क्लस्टर विचलित प्रोटोकॉल निर्धारित करता है। सबसे निचली परत से गिनते हुए, सबसे अधिक मेल खाने वाली ISO/OSI परतों वाला नियम निर्णायक होता है। इसके ऊपर की पहली गैर-मेल खाने वाली परत प्रोटोकॉल को निर्धारित करती है।
• इस प्रोटोकॉल के लिए IdsM को एक SEv रिपोर्ट किया जाता है, जैसे SEV_FW_PACKET_BLOCKED_DATALINKLAYER_MISMATCH (Ethernet), SEV_FW_PACKET_BLOCKED_IPV4_MISMATCH, SEV_FW_PACKET_BLOCKED_IPV6_MISMATCH या SEV_FW_PACKET_BLOCKED_ICMP_MISMATCH।

ये विवरण R23-11 से आते हैं। संबंधित आवश्यकताएँ R25-11 पेलोड का हिस्सा नहीं हैं और इसलिए यहाँ व्याख्यात्मक रूप से दी गई हैं, मानक (normative) रूप से नहीं। आर्किटेक्चर विवरण के अनुसार, ब्लॉक किए गए संदेशों का SEvs के रूप में IdsM में जाने का सिद्धांत R25-11 (EXP_PlatformDesign पृ. 92) पर भी लागू होता है।

गतिविधि आरेख (Activity diagram): एक पैकेट की जाँच सक्रिय स्थिति के नियमों के विरुद्ध की जाती है। एक डिफ़ॉल्ट ब्लॉक IdsM को प्रोटोकॉल-विशिष्ट SEv की ओर ले जाता है। स्रोत: EXP_PlatformDesign पृ. 92, SWS_Firewall पृ. 31 (R23-11)

त्रुटि की स्थिति में व्यवहार

मॉड्यूल के त्रुटि कोड FwErrc द्वारा हेडर ara/fw/fw_error_domain.h में परिभाषित किए गए हैं: kServiceNotAvailable=1 और kInvalidStateDependentFirewall=2 [AP_SWS_Fw_83001]। दोनों को SwitchFirewallState के लिए संभावित त्रुटियों के रूप में निर्दिष्ट किया गया है [AP_SWS_Fw_82008]। नामों की व्याख्या, क्योंकि आवश्यकताएँ ट्रिगर शर्तों का उल्लेख नहीं करती हैं:

• kServiceNotAvailable द्वारा यह रिपोर्ट किए जाने की संभावना है कि डेमॉन-आधारित FC Firewall सेवा प्रदान करने में असमर्थ है। प्रश्न (खुला)
• kInvalidStateDependentFirewall द्वारा यह रिपोर्ट किए जाने की संभावना है कि अनुरोधित स्थिति के लिए कोई मान्य StateDependentFirewall उपलब्ध नहीं है। प्रश्न (खुला)

त्रुटि डोमेन सामान्य ara::core पैटर्न का अनुसरण करता है:

• GetFwErrorDomain() डोमेन को थ्रेड-सुरक्षित रूप से प्रदान करता है [AP_SWS_Fw_83002]। FwErrorDomain का डिफ़ॉल्ट कंस्ट्रक्टर हटा दिया गया है [AP_SWS_Fw_83009]।
• MakeErrorCode एक ara::core::ErrorCode उत्पन्न करता है [AP_SWS_Fw_83003]।
• Name() और Message() डोमेन नाम और त्रुटि पाठ प्रदान करते हैं [AP_SWS_Fw_83010] [AP_SWS_Fw_83011]।
• उपनाम Errc और Exception FwErrc और FwException को संदर्भित करते हैं [AP_SWS_Fw_83007] [AP_SWS_Fw_83008]।

जो लोग अपवादों (exceptions) के साथ काम करते हैं, वे ThrowAsException के माध्यम से त्रुटि कोड को FwException में बदल सकते हैं। यह फ़ंक्शन noexcept(false) है और इसे "not exception safe" के रूप में वर्गीकृत किया गया है [AP_SWS_Fw_83012] [AP_SWS_Fw_83005]। इसके विपरीत, ब्लॉक किए गए पैकेट कोई API त्रुटि नहीं हैं। वे IdsM में Security Events के रूप में दिखाई देते हैं (EXP_PlatformDesign पृ. 92)।

गतिविधि आरेख (Activity diagram): स्थिति परिवर्तन के परिणाम का मूल्यांकन Future के माध्यम से किया जाता है। त्रुटियाँ FwErrorDomain के माध्यम से चलती हैं और वैकल्पिक रूप से FwException के रूप में फेंकी (throw) जा सकती हैं। स्रोत: [AP_SWS_Fw_82008], [AP_SWS_Fw_83001], [AP_SWS_Fw_83011], [AP_SWS_Fw_83012]

आगे विस्तृत साक्ष्य

निम्नलिखित अंश इस गाइड के कथनों का समर्थन करते हैं; आवश्यकताएँ R25-11 ([AP_SWS_Fw_82008]) के लिए मानक (normative) हैं।

• [AP_SWS_Fw_82008]: रिटर्न प्रकार और त्रुटि सूची के साथ एकमात्र कार्यात्मक ऑपरेशन।
• [AP_SWS_Fw_82002], [AP_SWS_Fw_82003]: इंटरफ़ेस क्लास का निर्माण और विनाश, थ्रेड-सुरक्षा सहित।
• [AP_SWS_Fw_81001], [AP_SWS_Fw_81002]: जनरेट किए गए स्थिति प्रकार।
• [AP_SWS_Fw_83001], [AP_SWS_Fw_83012]: त्रुटि कोड और अपवादों में रूपांतरण।
• EXP_SWArchitecture पृ. 126, EXP_SWArchitecture पृ. 197: इंटरफ़ेस और उपयोग के मामले (Use Cases)।
• EXP_SWArchitecture पृ. 232: स्थिति परिवर्तन का अनुक्रम। R22-11 का पूर्ववर्ती संस्करण EXP_SWArchitecture पृ. 158 में है।
• TPS_ManifestSpecification पृ. 263, TPS_ManifestSpecification पृ. 679: स्टेट मशीन और नियम मॉडल।
• TPS_SystemTemplate पृ. 644: StateDependentFirewall का संक्षिप्त विवरण। R23-11 का संस्करण TPS_SystemTemplate पृ. 583 में है।
• SWS_Firewall पृ. 31: डिफ़ॉल्ट ब्लॉकिंग पर SEv असाइनमेंट, केवल संस्करण R23-11 में।