Entwicklung und Verifikation der Logistikanforderungen
This article is in German an first appeared on systems-engineering.ch in November 2014
Wie auch alle übrigen Anforderungen, so leiten sich die Logistikanforderungen aus der Missionsanalyse und den operationellen Systemanforderungen ab. Aus den operationellen Anforderungen ergeben sich auch konkrete Vorgaben zur Beanspruchung, Verfügbarkeit und Wartbarkeit. Figur 1 zeigt ein konzeptionelles, operationelles Modell eines Systems unter Berücksichtigung aller in [5] postulierten Lebenszyklusphasen. Sämtliche Elemente dieses Modells, und damit insbesondere auch die Reliability, Availability, Maintainability und Safety (RAMS) müssen durch die operationellen, funktionalen, Performance- und Detailanforderungen geeignet abgedeckt werden. Bei der Erarbeitung des OpsCon [11] und der Functional Analysis [6] ist die Logistik also ein unverzichtbarer Bestandteil (s. auch [8] Kap. 2, 3 & 6).
Supportability factors are integral elements of program performance specifications. However, support requirements are not to be stated as distinct logistics elements, but instead as performance requirements that relate to a system’s operational effectiveness, operational suitability, and life-cycle cost reduction (DoD 5000.2-R, aus [2] Kap. 5.1).
Figur 1: System Concept of Operations Model (Quelle: [9] Fig. 18.2)
Logistikanforderungen sind Teil der formellen Performance und Detail Specifications der Systeme und deren Elemente auf allen Stufen. Damit wird die Verpflichtung begründet, auch für Logistikanforderungen entsprechende Verifikationsanforderungen zu entwickeln und die Erfüllung der Anforderungen geeignet zu verifizieren und zu validieren. In [2] Kap. 6.2.3 findet man das folgende Beispiel für eine Performance- und zugehörige Verifikationsanforderung zu Operational Sustainability (mit ORD ist hier ein OpsCon gemeint):
(Requirement) The portable control station will be capable of completing a sustained 4-day operation using only onboard equipment and spares without resupply or support from personnel other than the operators.
(Verification) The operational test of the system will be used to verify the requirement is met. The test will consist of 2 systems performing 4 each of Scenario A, as identified in the ORD, and 2 each of Scenario B (surge), as identified in the ORD. Nine of the 12 scenarios must be fully executed without outside resupply/assisted maintenance. Additionally, at least one surge scenario must be completed without outside resupply/assisted maintenance.
Figur 2 zeigt schematisch die Einbettung der LSA in die Functional Analysis als wesentliche Voraussetzung für die Lösungssynthese. Einen Leitfaden für diese Phase im Bereich Flugsicherung findet man z.B. in [7] Kap. 3.2 und 3.3.
Figur 2: Systems engineering to implement supportability requirements (Quelle: [8] A.6)
Aus den obigen Ausführungen lässt sich die Verpflichtung zur Verifikation und Validierung von Logistikanforderungen als integraler Bestandteil der formalen Abnahmeaktivitäten direkt ableiten. Auch die referenzierten Dokumente äussern sich in dieser Hinsicht eindeutig; sie enthalten zahlreiche Vorgaben zu logistikorientierten Verifikationsverfahren. Es sei hier besonders auf [4] Kap. 11 verwiesen, woraus auch das folgende Zitat stammt:
Logistics Test And Evaluation Extends Over The Entire Acquisition Cycle, And Includes Development Test & Evaluation (DT&E), Operational Test & Evaluation (OT&E), And Supportability Assessments.
In einer Systembeschaffung des U.S. DoD sind also üblicherweise sowohl DT&E als auch OT&E vorgesehen. Festzulegen bleiben Inhalt, Umfang, Deckungsgrad und Detailtiefe der formalen Verifikationsaktivitäten und das dafür verfügbare Budget. Zur Verantwortlichkeit für die Berücksichtigung der Logistik in den Verifikationsaktivitäten äussert sich [4] wie folgt (Kap. 25.3.2.1):
Supportability of a system should be demonstrated before deployment. The logistics manager must ensure that the Test and Evaluation Master Plan (TEMP) includes supportability objectives, issues, and criteria.
MIL-STD-1388-1A erkennt in Task 500 zwei Arten von Supportability Assessments: diejenigen vor Einführung als Teil des formalen Test- and Evaluation Programs, und diejenigen nach Einführung mittels Analyse von Daten aus der Benützung und Wartung der Systeme in der operationellen Umgebung (s. [1] Kap. 50.5.1.1 ff). Auch aus ISO 15288 [5] ergibt sich die Verpflichtung, das Support-System zusammen mit den Nutzsystemen denselben Verifikations- und Validierungsmassnahmen zu unterwerfen, unabhängig davon, ob Organisationen des Auftraggebers oder des Systemlieferanten für den Betrieb der Support-Systeme oder Teilen davon zuständig sind.
Task 501 (s. [1] Kap. 50.5.2.1 ff) enthält detailierte Anforderungen zur Planung, Vorbereitung, Durchführung und Auswertung von Supportability Verification im Kontext von DT&E und OT&E des Nutzsystems. In [8] Seite 12.32 ff und Seite 4.27 findet man weitere Erläuterungen; hier folgender Auszug:
The object of the [supportability] demonstration is to take an operational system, induce failures into the system, and use only the technical manuals and support system that will be available to maintenance personel when the system is fielded to find and fix the failure. It is best if actual service technicians perform the maintenance [...].
Voraussetzung für die Erfolgreiche Durchführung einer solchen Demonstration ist, dass die im Support System vorgesehenen Prozesse und Infrastruktur implementiert sind, und Techniker und Operateure mit vorgeschriebener Qualifikation vor Ort sind. Die Demonstration kann aufdecken, ob die vorgeschriebene Verfügbarkeit und Reparaturdauer eingehalten werden, und ob die implementierten Fehlerlokalisierungsmittel (Built-in Tests, etc.) operationell wirksam sind. [8] nennt zahlreiche weitere Verifikationsmassnahmen (Reliability Analysis, Stress Screening, etc.).
Figur 3 zeigt den schematischen Ablauf der Logisikverifikation und dessen Einbettung in den Entwicklungsprozess zwischen Critical Design Review (CDR) und Functional Configuration Audit (FCA).
Figur 3: Testing to demonstrate supportability requirements achieved (Quelle: [8] A.8)
Referenzen
[1] Logistics Support Analysis, MIL-STD-1388-1A (canceled), 11.4.83, Department of Defense
[2] Acquisition Logistics, MIL-HDBK-502, 30.5.97, Department of Defense
[3] Designing and Developing Maintainable Products and Systems, MIL-HDBK-470A, 4.8.97, DoD
[4] Acquisition Logistics Guide, 3rd Edition, Dec. 97, Defense System Management College
[5] ISO/IEC Std 15288:2008: Systems and software engineering – System life cycle processes
[6] NAS System Engineering Manual (SEM), Version 3.1, 6.6.06, FAA
[7] Integrated Logistics Support Process Manual (ILSPM), Version 3, June 07, FAA
[8] Integrated Logistics Support Handbook, 3rd Edition, 2006, McGraw-Hill, Jones, James V
[9] System Analysis, Design, and Development Concepts, Principles and Practices, 2006, Wiley, Wasson, Charles
[10] Integrated Product and Process Development Handbook, Aug. 1998, Department of Defense
[11] ISO 29148:2011 Systems and software engineering – Life cycle processes – Requirements engineering