وحدة ara::diag — Diagnostics
دليل الوحدةمولَّد بالذكاء الاصطناعي
يوفر خدمات تشخيص قياسية، وبروتوكولات UDS وSOVD، بالإضافة إلى إدارة مركزية لذاكرة الأعطال.
يوفر خدمات تشخيص قياسية، وبروتوكولات UDS وSOVD، بالإضافة إلى إدارة مركزية لذاكرة الأعطال.
توفر المجموعة الوظيفية Diagnostic Management في AUTOSAR Adaptive Platform البنية التحتية المركزية لتشخيص المركبات الكلاسيكي UDS والحديث SOVD (AUTOSAR_AP_EXP_SWArchitecture ص. 150). وبصفتها خادم خلفية (daemon) للمنصة، فإنها تنهي طبقات النقل مثل DoIP، وتتحكم في معالجات البروتوكول، وتوجه طلبات التشخيص عبر واجهات استدعاء راجع آمنة للأنواع إلى Adaptive Applications ([SWS_DM_00311]). وفي الوقت نفسه، تتولى الوحدة مراقبة الأخطاء، وإزالة الارتداد الزمني وعدّاد الارتداد، وإدارة ذاكرة الأعطال. وتفعل التطبيقات دوال الخدمات عبر نموذج عرض (offer) تصريحي، مما يحافظ على فصل واضح بين منطق التطبيق ومعالجة البروتوكول.
توفر المجموعة الوظيفية Diagnostic Management (ara::diag) في AUTOSAR Adaptive Platform البنية التحتية المركزية القائمة على خادم خلفية لمعالجة اتصالات التشخيص الملائمة للمركبات (AUTOSAR_AP_EXP_SWArchitecture ص. 150). وهي تفصل معالجات البروتوكول الخاصة بالنقل (مثل DoIP أو CAN-TP) عن جوهر التشخيص الفعلي (UdsTransportProtocolMgr)، وبذلك تتيح إنهاءً وتوجيهًا موحدين لطلبات التشخيص (AUTOSAR_AP_EXP_SWArchitecture ص. 164).
مخطط السياق: تضمين خادم Diagnostic Management بين معالجات النقل، وAdaptive Applications، وأجهزة الاختبار الخارجية. المصادر: AUTOSAR_AP_EXP_SWArchitecture ص. 150، AUTOSAR_AP_EXP_SWArchitecture ص. 164، AUTOSAR_AP_EXP_SWArchitecture ص. 168
لمعالجة الخدمات، تنفذ الوحدة نموذج توفير تصريحي: ينفذ خادم التشخيص واجهات المنافذ، بينما تسجل Adaptive Applications استدعاءات راجعة للخدمة لـ DataIdentifier أو الإجراءات الروتينية أو عمليات النقل المعتمدة على الكتل وتتحكم في توفرها عبر Offer() أو StopOffer() ([SWS_DM_00557]، AUTOSAR_AP_EXP_SWArchitecture ص. 156). وتتم معالجة الرسائل الواردة بشكل آمن من الأخطاء عبر آليات إشعار وتسليم ثنائية المراحل (IndicateMessage وHandleMessage) ([SWS_DM_00309]، [SWS_DM_00311]).
مخطط تسلسلي: تدفق تحكم متكامل لطلب UDS من طبقة النقل عبر مدير التشخيص إلى التطبيق المستخدِم. المصادر: [SWS_DM_00309]، [SWS_DM_00311]، [SWS_DM_00327]، AUTOSAR_SWS_Diagnostics ص. 130
إلى جانب دوال UDS الكلاسيكية، تدير المجموعة أجهزة المراقبة التشخيصية، وتجري عمليات إزالة الارتداد المكوَّنة، وتثبّت الأخطاء المؤهلة في ذاكرة الأعطال الأساسية (DTCInformation) ([SWS_DM_00664]، SWS_Diagnostics ص. 225). وتُدمج المعايير المتقدمة مثل ISO 13400-2 (DoIP) وASAM SOVD (Service-Oriented Vehicle Diagnostics) بسلاسة في المنصة عبر واجهات متخصصة لخطوط التنشيط والمصادقات وبيانات حمولة JSON الهرمية ([SWS_DM_00834]، [SWS_DM_02370]، AUTOSAR_AP_EXP_SWArchitecture ص. 170).
الدور المعماري وحدود النظام لـ Diagnostic Management
تشكل المجموعة الوظيفية Diagnostic Management (ara::diag) في AUTOSAR Adaptive Platform (الإصدار R25-11) مركز التحكم المركزي للتشخيص الداخلي والخارجي للمركبة (AUTOSAR_AP_EXP_SWArchitecture ص. 150). ومن الناحية المعمارية، صُممت الوحدة كخدمة خلفية قائمة على خادم («aapFunctionalCluster» Diagnostic Management daemon-based). وتنهي بروتوكولات التشخيص المادية والمنطقية، وتدير سياق التشخيص العام، وتوفر البنية التحتية للبرمجيات الوسيطة التي يمكن لـ Adaptive Applications الفردية من خلالها توفير البيانات والإجراءات الروتينية المتعلقة بالتشخيص (AUTOSAR_AP_EXP_SWArchitecture ص. 156).
تنقسم بيئة الواجهات في المقام الأول إلى فئتين: واجهات المنافذ المنمذجة، التي يتم تكوينها عبر بيان (manifest) AUTOSAR وربطها بعمليات التطبيق، وواجهات وقت تشغيل C++ الأصلية (AUTOSAR_AP_EXP_SWArchitecture ص. 150). وتشمل الواجهات الأصلية بوجه خاص الفئة Conversation، التي يمكن للتطبيقات من خلالها الاستعلام عن حالات الجلسة الحالية ([SWS_DM_00696])، أو تحديد مستويات الأمان ([SWS_DM_00698])، أو فحص محادثات التشخيص النشطة ([SWS_DM_00783]). تفسير: يُفترض أن الفصل الصارم بين خادم التشخيص المركزي والعمليات المستخدِمة قد اختير لضمان أوقات استجابة حتمية تجاه أجهزة الاختبار الخارجية حتى عند إعادة تشغيل عمليات التطبيقات الفردية. سؤال Q-2e2ea8eb9d415fed (مفتوح)
مخطط السياق: تضمين خادم Diagnostic Management بين معالجات النقل، وAdaptive Applications، وأجهزة الاختبار الخارجية. المصادر: AUTOSAR_AP_EXP_SWArchitecture ص. 150، AUTOSAR_AP_EXP_SWArchitecture ص. 164، AUTOSAR_AP_EXP_SWArchitecture ص. 168
ربط طبقة النقل والتحكم في دورة حياة معالجات البروتوكول
للعمل باستقلالية عن تقنيات الشبكات المحددة (مثل Ethernet/DoIP أو CAN/ISO-TP)، تفصل Diagnostic Management جوهر البروتوكول عبر واجهات نقل قياسية (AUTOSAR_AP_EXP_SWArchitecture ص. 164). وينفذ الجوهر العام الواجهة UdsTransportProtocolMgr، بينما يتم ربط المحولات الخاصة بالنقل كـ UdsTransportProtocolHandler (AUTOSAR_AP_EXP_SWArchitecture ص. 165). ويتم تحديد كل معالج عبر معرّف فريد يمكن الاستعلام عنه عبر GetHandlerID() ([SWS_DM_00325]).
ينقسم التحكم في دورة حياة معالج النقل إلى مراحل تشغيل حتمية (AUTOSAR_SWS_Diagnostics ص. 128): أثناء بدء التشغيل، تهيئ Diagnostic Management المعالج عبر Initialize() ([SWS_DM_00319]) ثم تنشط بعد ذلك معالجة الرسائل بواسطة Start() ([SWS_DM_00322]). وعند الإنهاء المنضبط، يطلب المدير من المعالج عبر Stop() إغلاق الاتصالات المفتوحة ([SWS_DM_00323])، حيث يؤكد المعالج بعد ذلك الإتمام عبر HandlerStopped() ([SWS_DM_00314]).
بالنسبة لجلسات التشخيص طويلة الأمد، تحدد AUTOSAR علاوة على ذلك آلية استعادة عبر دورات حياة العمليات (AUTOSAR_SWS_Diagnostics ص. 134). وإذا أمكنت إعادة إنشاء قناة تم حفظها مسبقًا بعد إعادة تشغيل مدير التشخيص، يبلّغ معالج النقل عن ذلك عبر NotifyReestablishment() ([SWS_DM_00326]). يقوم المدير بمزامنة الحالة داخليًا ويؤكد ذلك باستدعاء ChannelReestablished() ([SWS_DM_00313]).
مخطط تسلسلي: التحكم في دورة حياة معالج نقل UDS بواسطة مدير التشخيص العام. المصادر: [SWS_DM_00314]، [SWS_DM_00319]، [SWS_DM_00322]، [SWS_DM_00323]، AUTOSAR_SWS_Diagnostics ص. 128
معالجة خدمة UDS ومعالجة الطلبات الخاصة بالتطبيق
تتم معالجة رسائل UDS الواردة خطوة بخطوة بعد التحقق من صحة البروتوكول (AUTOSAR_SWS_Diagnostics ص. 130). في البداية، يعلن معالج النقل عن رسالة تبدأ عبر IndicateMessage() لدى المدير لتخصيص الموارد وذاكرات التخزين المؤقت ([SWS_DM_00309]). يتم تغليف الرسالة في صورة UdsMessage، والتي توفر عنوان المصدر ([SWS_DM_00297])، وعنوان الوجهة ([SWS_DM_00298])، ونوع العنونة ([SWS_DM_00299]). بعد الاستلام الكامل، يسلم المعالج كائن البيانات عبر HandleMessage() إلى Diagnostic Management ([SWS_DM_00311])، مع استكمال معلومات وصفية خاصة بالقناة بواسطة AddMetaInfo() ([SWS_DM_00302]).
في الإصدار R25-11، يتبع التفاعل بين برنامج المنصة الخفي والتطبيق نموذج تقديم خدمة معكوسًا (AUTOSAR_AP_EXP_SWArchitecture ص. 156): ينفذ برنامج المنصة الخفي منافذ الخدمة، بينما تنفذ Adaptive Applications دوال رد الاتصال وتفعّل جاهزيتها لإعادة التوجيه صراحةً عبر Offer() ([SWS_DM_00557]) أو تعلّقها عبر StopOffer() ([SWS_DM_00558]). ينطبق هذا بالمثل على الإجراءات العامة (GenericRoutine [SWS_DM_00552])، والإجراءات محددة النوع (RoutineInterface [SWS_DM_00589] مع Start [SWS_DM_00591])، ومعرّفات البيانات (GenericDataIdentifier [SWS_DM_00634] مع Read [SWS_DM_00636] وWrite [SWS_DM_00637])، بالإضافة إلى خدمات UDS العامة (GenericUDSService [SWS_DM_00616] مع HandleMessage [SWS_DM_00618]).
تتم معالجة معاملات التشخيص الأطول مدةً (مثل عمليات نقل الكتل عبر UploadService [SWS_DM_00797]، أو DownloadService [SWS_DM_00787]، أو FileTransferService [SWS_DM_01325] وفقًا لـ AUTOSAR_AP_EXP_SWArchitecture ص. 163) بشكل غير متزامن عبر ara::core::Future. ولتجنب حظر الموارد، تتلقى المعالجات الخاصة بالتطبيق نسخة من CancellationHandler (AUTOSAR_AP_EXP_SWArchitecture ص. 152). عبر IsCanceled()، يمكن للتطبيق الاستعلام عن الإلغاء ([SWS_DM_00614]) أو تسجيل دالة إشعار عبر SetNotifier() ([SWS_DM_00615]). ولعمليات إعادة التشغيل المنسقة، يتم توفير الواجهة EcuResetRequest ([SWS_DM_01010])، والتي تفوّض طلبات إعادة الضبط إلى State Management (AUTOSAR_AP_EXP_SWArchitecture ص. 162).
مخطط تسلسلي: تدفق تحكم متكامل لطلب UDS من طبقة النقل عبر مدير التشخيص إلى التطبيق المستخدِم. المصادر: [SWS_DM_00309]، [SWS_DM_00311]، [SWS_DM_00327]، AUTOSAR_SWS_Diagnostics ص. 130
مراقبة الأحداث وإزالة الارتداد وإدارة ذاكرة الأعطال
لتسجيل أخطاء النظام وتأهيلها، تنفذ Diagnostic Management نموذجًا هرميًا يتألف من شاشات مراقبة وأحداث تشخيص (SWS_Diagnostics ص. 225). ينشئ التطبيق مثيلًا من كائن Monitor ([SWS_DM_00548]) ويبلّغ عن نتائج الاختبار باستمرار عبر ReportMonitorAction() ([SWS_DM_00543]). تدعم الوحدة في هذا السياق كلاً من خوارزميات إزالة الارتداد المستندة إلى العدادات وتلك المستندة إلى الوقت ([SWS_DM_00549]، [SWS_DM_00550]). عبر الواجهة Event، يمكن للتطبيقات تحديد قيمة بايت حالة UDS الحالية ([SWS_DM_00649])، أو فحص حالة إزالة الارتداد ([SWS_DM_00654])، أو تسجيل استدعاءات رد نداء لتغير الحالة ([SWS_DM_00650]).
للحفاظ على تقليل بصمة المنفذ في الأنظمة المعقدة، توفر المنصة واجهات مجمعة (AUTOSAR_AP_EXP_SWArchitecture ص. 153): عبر MultipleMonitor ([SWS_DM_01695])، وMultipleEvent ([SWS_DM_01705])، وMultipleCondition ([SWS_DM_01727])، يمكن عنونة قنوات مراقبة متعددة عبر واجهة منفذ مشتركة. تتم إدارة التمكين لشاشات المراقبة عبر كائنات Condition ([SWS_DM_00712])، بينما تتحكم OperationCycle ([SWS_DM_00752]) وIndicator ([SWS_DM_00742]، SWS_Diagnostics ص. 633) في دورات التشغيل وتشير إلى طلبات مصابيح التحذير.
تصب الأحداث المجمعة في إدارة ذاكرة الأعطال، والتي يتم كشفها عبر DTCInformation ([SWS_DM_00664]، AUTOSAR_AP_EXP_SWArchitecture ص. 144). تتيح هذه الواجهة قراءة الإدخالات المخزنة ([SWS_DM_00669])، والحذف الانتقائي أو الشامل لرموز DTC ([SWS_DM_00671])، وتفعيل تسجيل DTC ([SWS_DM_00674]). وإذا حدث تجاوز لسعة الذاكرة الأساسية، يتم إخطار التطبيق عبر SetEventMemoryOverflowNotifier() ([SWS_DM_00918]، [SWS_DM_00919]).
مخطط الحالة/النشاط: المسار من إجراء شاشة المراقبة عبر إزالة الارتداد وصولاً إلى تأهيل DTC في ذاكرة الأعطال. المصادر: [SWS_DM_00543]، [SWS_DM_00649]، [SWS_DM_00664]، SWS_Diagnostics ص. 225
بروتوكولات التشخيص الموسعة: تكامل DoIP وخدمات SOVD
لشبكات المركبات القائمة على Ethernet، تدمج الوحدة وظائف DoIP مخصصة (بروتوكول اتصالات التشخيص عبر بروتوكول الإنترنت وفقًا للمعيار ISO 13400-2) (AUTOSAR_AP_EXP_SWArchitecture ص. 166، AUTOSAR_AP_EXP_SWArchitecture ص. 167). تبلّغ ملحقات المنصة عن حالة خطوط التنشيط المادية عبر DoIPActivationLine::UpdateActivationLineState() ([SWS_DM_00834]، AUTOSAR_AP_TPS_ManifestSpecification ص. 338). وبناءً على ذلك، يمكن إطلاق رسائل إعلان المركبة (Vehicle Announcement Messages) عبر DoIPTriggerVehicleAnnouncement ([SWS_DM_00821]، [SWS_DM_00822]، AUTOSAR_AP_SWS_Diagnostics ص. 108). ويتم الاستعلام ديناميكيًا عن تعريف المجموعة والكيان عبر DoIPGroupIdentification ([SWS_DM_00722]) وDoIPEntityIdentification ([SWS_DM_01364]، [SWS_DM_01366]).
مخطط تسلسلي: التفاعل بين التطبيق وخط التنشيط وإطلاق إعلانات مركبة DoIP. المصادر: [SWS_DM_00822]، [SWS_DM_00834]، AUTOSAR_AP_SWS_Diagnostics ص. 108
بالإضافة إلى خدمات UDS الكلاسيكية، يرسخ الإصدار R25-11 واجهات أصلية لـ SOVD (Service-Oriented Vehicle Diagnostics، ASAM SOVD / ISO 13170) (AUTOSAR_AP_EXP_SWArchitecture ص. 168). يتم تصميم بيانات التشخيص المهيكلة عبر DiagnosticSovdContentElementData ([SWS_DM_02370]، AUTOSAR_AP_EXP_SWArchitecture ص. 170). ولمعالجة حمولات البيانات المعقدة المشابهة لـ JSON، تتوفر فئات آمنة النوع شبيهة بـ STL مثل DiagnosticSovdArrayContentElementDataView ([SWS_DM_02245]، AUTOSAR_AP_EXP_SWArchitecture ص. 172) وDiagnosticSovdRecordContentElementDataView ([SWS_DM_02289]، AUTOSAR_AP_EXP_SWArchitecture ص. 174).
لمعاملات SOVD المتقدمة وإجراءات الحماية، تحدد الوحدة أدوارًا قياسية: يتم نقل كميات البيانات الكبيرة (مثل التتبعات أو تفريغات الأعطال) عبر SovdBulkData ([SWS_DM_01847]، [SWS_DM_01854]، AUTOSAR_AP_TPS_ManifestSpecification ص. 321). ويتم التحكم في الوصول عبر عمليات التحقق من الرمز المميز والتقارب بواسطة SovdAuthorization ([SWS_DM_01489]) وSovdProximityChallenge ([SWS_DM_01480]، [SWS_DM_01493])، بينما يتم التصريح بفحوصات الخدمة عبر SovdServiceValidation ([SWS_DM_01823]، [SWS_DM_01827]).
التصرف في حالة الخطأ
تستند إدارة الأخطاء في الوحدة diag إلى نمط AUTOSAR القياسي ara::core::Result<T, ErrorCode> وتستبعد حالات الخطأ الصامتة تمامًا. يتم تقسيم الأخطاء وفقًا لأسبابها الوظيفية إلى خمسة نطاقات أخطاء متخصصة (ErrorDomain)، والتي تحدد كلاً من رموز الأخطاء وفئات الاستثناءات المقابلة:
- أخطاء التشخيص العامة: تشير
DiagErrorDomain([SWS_DM_00520]، [SWS_DM_00524]) وفئةDiagException([SWS_DM_00516]) المرتبطة بها إلى أخطاء المنصة أو التكوين الأساسية، مثل الوسيطات غير الصالحة أو النسخ غير المهيأة. - رموز الاستجابة السلبية لـ UDS (NRC): يتم تمثيل حالات الرفض الخاصة ببروتوكول UDS وفقًا للمعيار ISO 14229 عبر
DiagUdsNrcErrorDomain([SWS_DM_00532]، [SWS_DM_00536]) وDiagUdsNrcException([SWS_DM_00528]). - أخطاء تقديم الخدمة: في حالة فشل تفعيل واجهات المنافذ أو إلغاء تفعيلها، يتم تطبيق
DiagOfferErrorDomain([SWS_DM_00992]، [SWS_DM_01003]) معDiagOfferException([SWS_DM_00986]). - أخطاء إبلاغ الأحداث وشاشات المراقبة: يُشار إلى الأخطاء أثناء إبلاغ حالة شاشات المراقبة بواسطة
DiagReportingErrorDomain([SWS_DM_00999]، [SWS_DM_01004]) وDiagReportingException([SWS_DM_00988]). - أخطاء بروتوكول SOVD: يتم الإبلاغ عن الأخطاء في نقاط نهاية REST، أو محتويات JSON، أو التحكم في الوصول عبر
DiagSovdErrorDomain([SWS_DM_01812]، [SWS_DM_01816]) وDiagSovdException([SWS_DM_01808]).
على مستوى طبقة النقل، يتم الإبلاغ عن حالات إلغاء الإرسال، أو فيضان المخزن المؤقت، أو انقطاع الاتصال إلى Diagnostic Management بواسطة رد النداء NotifyMessageFailure() ([SWS_DM_00310]). يتيح ذلك للوحدة تحرير الموارد المخصصة على الفور وبدء إرسال رسائل استجابة سلبية إلى جهاز الفحص إذا لزم الأمر.
مخطط الفئات: بنية نطاقات الأخطاء وتعيين رموز الاستثناءات والأخطاء القياسية في Diagnostic Management. المصادر: [SWS_DM_00520]، [SWS_DM_00532]، [SWS_DM_00992]، [SWS_DM_00999]، [SWS_DM_01812]
أدلة تفصيلية إضافية
تعتمد القاعدة المعيارية للوحدة diag على ثلاثة أعمال مواصفات مركزية في AUTOSAR Adaptive Platform:
- بنية الواجهات والمكونات: تم توثيق واجهات النظام، ونموذج البرنامج الخفي، والفصل بين طبقتي النقل والتطبيق في
AUTOSAR_AP_EXP_SWArchitecture(AUTOSAR_AP_EXP_SWArchitecture ص. 150، AUTOSAR_AP_EXP_SWArchitecture ص. 164، AUTOSAR_AP_EXP_SWArchitecture ص. 168). - مواصفات Diagnostic Management: تحدد
AUTOSAR_SWS_Diagnosticsتوقيعات API التفصيلية، وتسلسلات معالجة الطلبات، ودورات حياة معالجات النقل، وقواعد إزالة الارتداد (AUTOSAR_SWS_Diagnostics ص. 128، AUTOSAR_SWS_Diagnostics ص. 130، SWS_Diagnostics ص. 225). - تعريفات البيان والنموذج الفوقي: تنظم
AUTOSAR_AP_TPS_ManifestSpecificationالربط التصريحي لواجهات المنافذ، ومنطق التحقق، وتعيينات الخدمات بمكونات البرمجيات (AUTOSAR_AP_TPS_ManifestSpecification ص. 311، AUTOSAR_AP_TPS_ManifestSpecification ص. 321، AUTOSAR_AP_TPS_ManifestSpecification ص. 341).
تم إنشاء دليل الوحدات هذا بناءً على مواصفات AUTOSAR Adaptive للإصدار R25-11. جميع المتطلبات المعيارية مأخوذة من وثائق SWS ووثائق البنية المعمارية المشار إليها.
function: 755 variable: 102 class: 79 type alias: 45 struct: 39 enumeration: 35
خريطة المواضيع
ara::diag
131لا توجد بيانات عناصر لهذا الإصدار
<DataElement-Namespace>
DiagnosticDataElementInterface class
<DataIdentifier-Namespace>
DiagnosticDataIdentifierInterface class
<ExtendedDataRecord-Namespace>
DiagnosticExtendedDataRecordInterface class
<RoutineInterface-Namespace>
DiagnosticRoutineInterface class
apext::diag::uds_transport
class represents an UDS message exchanged between DM generic core (UdsTransport ProtocolMgr) and a specific implementation of UdsTransportPr
Abstract Class, which a specific UDS Transport Protocol (plugin) shall subclass.
The UdsTransportProtocolMgr class manages the interaction between the Diagnostic Server instance(s) and various UDS Transport Protocols (e.g
UdsTransportProtocolPeriodicHandler class to support 0x2A service from ISO.
This is the type of ByteSpan.
using ByteSpan = ara::core::Span<ara::core::Byte>;This is the identification of channel on which to transmit.
using ChannelID = std::uint32_t;This is the unique_ptr for constant UdsMessages containing a custom deleter as provided by the generic/core DM part towards the UdsTransportLayer-Plugin.
using UdsMessageConstPtr = std::unique_ptr<const UdsMessage, std::function<void(const UdsMessage*)>>;This is the unique_ptr for UdsMessages containing a custom deleter as provided by the generic/ core DM part towards the UdsTransportLayer-Plugin.
using UdsMessagePtr = std::unique_ptr<UdsMessage, std::function<void(UdsMessage*)>>;UdsTransportProtocolHandler are flexible "plugins", which need an identification.
using UdsTransportProtocolHandlerID = std::uint8_t;ara::diag
Class to implement the Service Authentication interfaces to application.
CancellationHandler contains a shared state if the processing should be cancelled.
Interface for the application to inform the Diagnostic Server instance about the authentication states and the user roles that are currently
Definition of the ClientAuthenticationHandle which is returned to the application when an AuthenticationState is set by the application.
0x28 CommunicationControl interface
DiagnosticConditionInterface.
Conversation interface.
Represents the parameters for counter-based debouncing.
Specifies the Concurrency type of a DataIdentifier related port.
Handles data transfers initiated by RequestReadFile/-Directory with data pulled by AraDiag from the implementation.
Handles data transfers initiated by RequestReadFile/-Directory with data pushed by the implementation.
Encapsulates all data transfer reading variants.
Handles data transfers initiated by AddFile, ResumeFile or ReplaceFile ModeOfOperation handling per requested RequestWriteFile.
Encapsulates all data transfer writing variants.
Error domain for diagnostic errors.
يرث من ara::core::ErrorDomain
Exception type thrown by Diag classes.
يرث من ara::core::Exception
Definition of the DiagnosticServiceDynamicAccessList class, which is used by the application to build a DynamicAccessList.
Const iterator for a DiagnosticSovdArrayContentElementData.
Const view on a DiagnosticSovdContentElementData with Array type.
Iterator for a DiagnosticSovdArrayContentElementData.
View on a DiagnosticSovdContentElementData with Array type.
The DiagnosticSovdContentData declaration.
Diagnostic SOVD Abstract Content Data.
A DiagnosticSovdContentElementData with associated key.
Const iterator for a DiagnosticSovdRecordContentElementData.
Const view on a DiagnosticSovdContentElementData with Record type.
Iterator for a DiagnosticSovdRecordContentElementData.
View on a DiagnosticSovdContentElementData with Record type.
Error domain for diagnostic offer errors.
يرث من ara::core::ErrorDomain
Exception type thrown by Diag classes.
يرث من ara::core::Exception
Error domain for diagnostic reporting errors.
يرث من ara::core::ErrorDomain
Exception type thrown by Diag classes.
يرث من ara::core::Exception
Error domain for errors originating from SOVD.
يرث من ara::core::ErrorDomain
Exception type for SOVD thrown by Diag classes.
يرث من ara::core::Exception
Error domain for errors originating from several diagnostic classes.
يرث من ara::core::ErrorDomain
Exception type thrown by Diag classes.
يرث من ara::core::Exception
DiagnosticDoIPActivationLineInterface.
DoIPEntityIdentification class to obtain the EID if required.
DoIPGroupIdentificationInterface.
DiagnosticDoIPPowerModeInterface.
DiagnosticDoIPTriggerVehicleAnnouncement.
Download service interface.
Class to implement operations on DTC informations per configured DiagnosticMemory Destination.
Definition of the DynamicAccessListDiagServiceBuilder class, which is used by the application to build a DynamicAccessList.
Service EcuReset Request interface.
Class to implement operations on diagnostic Events.
Current event status byte, bit-encoded.
Definition of the ExternalAuthentication class, which is used by the application to receive an instance of the ClientAuthentication Class re
File Transfer service interface.
Generic DataIdentifier interface.
Generic Diagnostic SOVD Content interface.
Generic Diagnostic SOVD Operation interface .
Generic Routine interface.
Generic UDS interface.
Definition of HTTP-Redirect
DiagnosticIndicatorInterface provides functionality for handling indicators.
Metainfo interface.
Class to implement operations on diagnostic Monitor interface.
Class for multiple condition operations.
Class to implement operations on diagnostic Events with the multiple event interfaces.
Class to implement monitor operations on the multiple monitor interfaces.
DiagnosticOperationCycleInterface provides functionality for handling of operation cycles.
ReleaseHandler contains a shared state if the processing should be cancelled.
DiagnosticSecurityAccessInterface.
DiagnosticServiceValidationInterface.
Class to implement the SOVD Authorization interfaces in the application.
Generic SOVD Bulk Data interface.
Generic SOVD Configuration interface.
Specifies the Concurrency type of a SOVD Content related port.
Interface to handle the SOVD Operation Execution .
Class to implement the SOVD proximity_challenge interfaces in the application.
Holds the data returned by the SovdProximityChallenge::GetChallenge()
Class to implement manufacturer-/supplier-specific checks for SOVD in the application.
Class to implement the SovdSwUpdate interface.
Represents the parameters for time-based debouncing.
Class to implement the subfunction TransmitCertificate (29 04) of UDS service Authentication as interface to application
Upload service interface.
Obtain the reference to the single global DiagErrorDomain instance.
constexpr const ara::core::ErrorDomain & GetDiagDomain () noexcept;Obtain the reference to the single global DiagErrorDomain instance.
constexpr const ara::core::ErrorDomain & GetDiagOfferDomain () noexcept;Obtain the reference to the single global DiagReportingErrorDomain instance.
constexpr const ara::core::ErrorDomain & GetDiagReportingDomain () noexcept;Obtain the reference to the single global DiagSovdErrorDomain instance.
constexpr const ara::core::ErrorDomain & GetDiagSovdErrorDomain () noexcept;Obtain the reference to the single global DiagUdsNrcErrorDomain instance.
constexpr const ara::core::ErrorDomain & GetDiagUdsNrcDomain () noexcept;Create a new ErrorCode for DiagErrorDomain with the given support data type.
التحميلات الزائدة MakeErrorCode 5
constexpr ara::core::ErrorCode MakeErrorCode (DiagErrc code, ara::core::ErrorDomain::SupportDataType data) noexcept; SWS_DM_00525constexpr ara::core::ErrorCode MakeErrorCode (DiagUdsNrcErrc code, ara::core::ErrorDomain::SupportDataType data) noexcept; SWS_DM_00537constexpr ara::core::ErrorCode MakeErrorCode (DiagOfferErrc code, ara::core::ErrorDomain::SupportDataType data) noexcept; SWS_DM_01005constexpr ara::core::ErrorCode MakeErrorCode (DiagReportingErrc code, ara::core::ErrorDomain::SupportDataType data) noexcept; SWS_DM_01006constexpr ara::core::ErrorCode MakeErrorCode (DiagSovdErrc code, ara::core::ErrorDomain::SupportDataType data) noexcept; SWS_DM_01817Type for current activity status.
enum class ActivityStatusType : std::uint8_t {...};Specifies the Concurrency types.
enum class ConcurrencyType : std::uint8_t {...};Type for Condition status.
enum class ConditionType : std::uint8_t {...};Represents the status of the service processing.
enum class ConfirmationStatusType : std::uint8_t {...};Type for ControlDTCStatus status as requested by UDS service 0x85 ControlDTCSetting.
enum class ControlDtcStatusType : std::uint8_t {...};Determines transfer exit signal type.
enum class DataTransferExitType : ara::core::Byte {...};Debounce status of event.
enum class DebouncingState : std::uint8_t {...};Specifies the types of internal errors that can occur upon calling Offer or ReportMonitorAction.
enum class DiagErrc : ara::core::ErrorDomain::CodeType {...};The type of the SOVD content data.
enum class DiagnosticSovdContentElementDataType : std::uint8_t {...};The primitive content element value types.
enum class DiagnosticSovdPrimitiveContentValueType : std::uint8_t {...};The DiagOfferErrc enumeration defines the error codes for the DiagOfferErrorDomain.
enum class DiagOfferErrc : ara::core::ErrorDomain::CodeType {...};The DiagReportingErrc enumeration defines the error codes for the DiagReportingErrorDomain.
enum class DiagReportingErrc : ara::core::ErrorDomain::CodeType {...};Specifies the types of errors that can occur in SOVD services.
enum class DiagSovdErrc : ara::core::ErrorDomain::CodeType {...};Specifies the types of internal errors that can occur upon calling Offer or ReportMonitorAction. The error codes described are defined in ISO 14229-1:2020 [1], Table A.1 "Negative Response Codes". In AUTOSAR, the three negative response code ranges, 0x00, 0x01-0x7F and 0x80-0xFF are respected, however, the value 0xFF is used to internally indicate, that there is no further processing and no response handling foreseen.
enum class DiagUdsNrcErrc : ara::core::ErrorDomain::CodeType {...};Represents the type of the DTC format according to ISO 14229-1 [30].
enum class DTCFormatType : std::uint8_t {...};Single event status bits.
enum class EventStatusBit : std::uint8_t {...};Represents the state of an indicator.
enum class IndicatorStatusType : std::uint8_t {...};Represents the status information reported to AAs why the monitor may be re-initalized.
enum class InitMonitorReason : std::uint32_t {...};Represents the status of the key compare.
enum class KeyCompareResultType : std::uint8_t {...};Represents the status information reported by AAs being relevant for error monitoring.
enum class MonitorAction : std::uint32_t {...};The standard operation execution capabilities .
enum class OperationExecutionCapability : std::uint8_t {...};The operation execution status .
enum class OperationExecutionStatus : std::uint8_t {...};PowerMode as defined in ISO 13400-2 [2].
enum class PowerModeType : std::uint8_t {...};This is the type of ProximityChallengeResultType.
enum class ProximityChallengeResultType : std::uint8_t {...};HTTP method used in the SOVD request.
enum class SovdRequestMethod : std::uint8_t {...};Phase type for a SOVD update.
enum class SovdUpdatePhase : std::uint8_t {...};Status type for a SOVD update .
enum class SovdUpdateStatus : std::uint8_t {...};The Terminate Operation reason .
enum class TerminateOperationExecutionReason : std::uint8_t {...};UDS DTC status bits according to ISO 14229-1.
enum class UdsDtcStatusBitType : std::uint8_t {...};Type to identify a condition.
using ConditionHandleType = std::uint8_t;Type to identify an event.
using EventHandleType = std::uint32_t;Register a notifier function which is called if a diagnostic event is changed.
using EventStatusByteNotifier = std::function<void(EventStatusByte)>;Notifier function which is called if the monitor needs to be re-initialized.
using InitMonitorNotifier = std::function<void(InitMonitorReason)>;Type to identify an monitor .
using MonitorHandleType = std::uint32_t;This is the type of ProximityChallengeValidationResultType.
using ProximityChallengeValidationResultType = ProximityChallenge ResultType;The type of the requested reset.
using ResetRequestType = std::uint8_t;Type for the active security level. .
using SecurityLevelType = std::uint8_t;Type for the active diagnostic session. .
using SessionControlType = std::uint8_t;kCustomReset
constexpr ResetRequestType kCustomReset = 3;Default session according to IS0 14229-1.
constexpr SessionControlType kDefaultSession = 0x01;Extended diagnostic session according to IS0 14229-1.
constexpr SessionControlType kExtendedDiagnosticSession = 0x03;HardReset.
constexpr ResetRequestType kHardReset = 1;KeyOffOnReset.
constexpr ResetRequestType kKeyOffOnReset = 2;Security level locked.
constexpr SecurityLevelType kLocked = 0x00;Programming session according to IS0 14229-1.
constexpr SessionControlType kProgrammingSession = 0x02;Safety system diagnostic session according to IS0 14229-1.
constexpr SessionControlType kSafetySystemDiagnosticSession = 0x04;SoftReset.
constexpr ResetRequestType kSoftReset = 0;نطاقات الأسماء
- <DataElement-Namespace> 1 Klassen, 0 freie Funktionen
- <DataIdentifier-Namespace> 1 Klassen, 0 freie Funktionen
- <ExtendedDataRecord-Namespace> 1 Klassen, 0 freie Funktionen
- <RoutineInterface-Namespace> 1 Klassen, 0 freie Funktionen
- apext::diag::uds_transport 4 Klassen, 0 freie Funktionen
- ara::diag 78 Klassen, 10 freie Funktionen
مخطط الفئات UML للوحدة
Abgerundete Rahmen = Namespaces; hohle Dreieckspfeile = Vererbung (zeigt zur Basisklasse); graue Boxen = modulfremde bzw. externe Basisklassen. Klicken öffnet die Klassenseite.
gemini-3.8-flash-low· 2026-10-13 · الأصل الألماني