Entwicklung und Verifikation der Logistikanforderungen

30. November 2014 Keine Kommentare

Abstrakt

Im letzten Beitrag wurde erläutert, welchen Stellenwert ILS während der Systembeschaffung hat. Hier wird nun beschrieben, wie Logistikanforderungen entwickelt und verifiziert werden, bzw. welchen Zusammenhang die Logistikanforderungen mit den übrigen Systemanforderungen und den Aktivitäten des System Engineerings haben.

Referenzierte Dokumente

[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

Artikel

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).

System Concept of Operations Model

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.

Systems engineering to implement supportability requirements (Quelle: [8] A.6)

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 Be­nü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 Vali­dierungsmassnahmen 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)

Figur 3: Testing to demonstrate supportability requirements achieved (Quelle: [8] A.8)

Integrated Logistics Support im Kontext der Systembeschaffung

31. August 2014 Keine Kommentare

Abstrakt

Der vorliegende Beitrag leitet den Stellenwert des Integrated Logistics Supports (ILS) bereits während der Systembeschaffung aus verschiedenen Normen und Empfehlungen her. Der Artikel will damit der häufig zu beobachtenden Tendenz Gegensteuer geben, dass ILS faktisch wie eine funktionale Organisationseinheit fernab von der Systementwicklung gelebt wird (im Widerspruch zur Umschreibung „Integrated“ im Namen).

Referenzierte Dokumente

[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

Artikel

Der Standard ISO 15288 [5] definiert den Systembegriff und die Lebenszyklusprozesse (Life Cycle Processes), welche für ein System anwendbar sind. Der Standard unterscheidet das eigentliche Nutzsystem (System-of-Interest oder Mission System [9]) von den zugehörigen Unterstützungssystemen (bzw. Enabling Systems, darunter speziell das Support System [9], s. Fig. 1).

Throughout the life cycle of a system-of-interest, essential services are required from systems that are not directly a part of the operational environment, e.g., mass-production system, training system, maintenance system. Each of these systems enables a part, e.g., a stage of the life cycle of the system-of-interest to be conducted. Termed „enabling systems“, they facilitate progression of the system-of-interest through its life cycle ([5] Kap. 5.1.4).

The System of Interest Architecture

Figur 1: The System of Interest Architecture (Quelle: [9] Fig. 10.1)

Der Beschaffungsprozess eines Nutzsystems muss sämtliche über die Lebenszyklen benötigten Unterstützungssysteme mitberücksichtigen (so auch für Entwicklung, Produktion, V&V und Betrieb). Im Rahmen des System Engineerings (s. [6] und [9]) werden von integrierten Teams (Integrated Product Teams, IPT) operationelle und funktionale Anforderungen analysiert und geeigneten Elementen der Systemarchitektur zugeordnet; diese Elemente können Teil des Nutzsystems oder von Unterstützungssystemen sein. Wenn verschiedene Zuordnungsvarianten existieren, ist deren Optimierung ebenfalls Aufgabe des System Engineerings; so könnte eine Verfügbarkeitsanforderung z.B. zu einem redundanten Design im Nutzsystem oder auch zu einem Unterstützungssystem in Form eines hinreichend schnellen Reparaturzentrums führen.

Wenn geeignete Unterstützungssysteme noch nicht existieren, werden diese im allgemeinen zusammen mit dem Nutzsystem beschafft (wobei [5] rekursiv auch auf Unterstützungssysteme anzuwenden ist). Sowohl im Beschaffungsprozess des US Department of Defense (https://akss.dau.mil/dag/) wie auch der FAA (http://fast.faa.gov/) gibt es dazu umfangreiche Vorschriften und Leitfäden (s. [1], [2], [3], [4], [6] und [7]).

In der Praxis werden von diesen Organisationen für dieselben Konzepte teilweise verschiedene Begriffe verwendet (Life-Cycle Logistics, Lifecycle Engineering, Logistics Management, etc.).

Integrated Logistics Support (ILS) is the disciplined and unified management of all activities necessary to produce a supportable system design and a reasonable support capability to achieve a predetermined set of measurable objectives within an acceptable cost of ownership ([8] p. 1.1).

Integrated logistics support is the critical functional discipline that plans, establishes, and maintains an integrated logistics support system for the lifecycle all FAA products and services. The objective is to provide the required level of service to the end user at optimal lifecycle cost to the FAA for new investment programs and the sustainment of fielded products and services (FAA AMS Policy Kap. 4.3.1, bzw. [7]).

Grundsätzlich werden in der angewandten Logistik die folgenden Phasen unterschieden ([4] Kap. 2.3):

  1. Planung und Beschaffung/Entwicklung des Nutzsystems mit den gewünschten Wartbarkeitseigenschaften zusammen mit den erforderlichen Unterstützungssystemen (acquisition logistics or logistics engineering).
  2. Betrieb der Unterstützungssysteme zur Unterstützung während der Nutzung des Nutzsystems (tactical/operational logistics or product support).

Je nach Interpretation der obigen Definitionen beschäftigt sich ILS also ausschliesslich mit der ersten Phase oder zu einem variablen Grad auch mit der zweiten. In jedem Fall muss sich ILS im Rahmen der Abnahmeaktivitäten auch mit der zweiten Phase beschäftigen, wie in einem künftigen Beitrag noch zu zeigen sein wird.

Wenn man ILS als Disziplin betrachtet, so ist die Logistic Support Analysis (LSA) das Vorgehensmodell von ILS. LSA wurde in den 70er-Jahren vom DoD entwickelt und im MIL-STD-1388-1(A) standardisiert. Zur Unterstützung der Interpretation und Umsetzung des Standards ist umfangreiche Sekundärliteratur entstanden, darunter [8] als eines der etabliertesten Werke. Der Standard wurde inhaltlich auch von anderen Organisationen übernommen, so z.B. vom Britischen Verteidigungsministerium im Defence Standard 00-60. Die entsprechenden Tasks sind in Fig. 2 aufgelistet.

Figur 2: MIL-STD-1388-1A Logistic Support Analysis Tasks (Quelle: [8] Fig. 12.3)

Figur 2: MIL-STD-1388-1A Logistic Support Analysis Tasks (Quelle: [8] Fig. 12.3)

Ein aktueller Standard zu Logistics Support Analysis im Bereich AeroSpace ist der S3000L der Aerospace Industries Association (ASD), auf den in einem künfiten Artikel eingegangen wird.

Es sei hier erwähnt, dass Safety, Human Factors, Reliability, Maintainability und Availability Engineering (bzw. alle in [6] Kap. 4.8 genannten Disziplinen) grundsätzlich Speciality-Engineering-Disziplinen sind, ihre Anforderungen (direkt oder indirekt) aus den operationellen Anforderungen der Benützer ableiten (z.B. aus dem CONOPS), und von den ILS-Verantwortlichen geeignet in die LSA-Tasks und integrierten Teams eingebunden werden müssen (s. [2] Kap. 9). ILS bzw. Acquisition Logistics selbst müssen ebenso als integraler Bestandteil des System Engineerings verstanden und gelebt werden (s. [2] Kap.4); ILS kann und darf nicht als ein der Entwicklung nachgelagerter Teil einer funktionalen Organisation aufgefasst werden; genauso wie System Engineering ist ILS eine umfassende und integrierende Disziplin, und nicht eine funktionale Organisationseinheit (wie dies leider in europäischen Unternehmen auch heute bzw. 20 Jahre nach breiter Einführung und Bewährung des Integrated Product and Process Developments (IPPD, s. [10]) in den USA leider noch viel zu häufig anzutreffen ist).