Context:- SwedishDefence

The Swedish Defence Materiel Administration, FMV, is a governmental agency acting under the Swedish Ministry of Defence. FMV make sure that the Swedish Armed Forces have the equipment and logistic services they need to execute their mission. The equipment needed are mainly procured from civil companies. In order to properly use and maintain the equipment, information is needed. The DEXs specify the data needed to convey this information. The DEXs are part of the contract and makes sure that FMV and the Swedish Armed Forces receives the data needed. Further information can be found at www.fmv.se.

The DEXs and templates presented below are in continuous development. Published DEX-packages can be found at plcs.fmv.se.

The overall business process for this Business Context is described by the prescriptive scenario below. The scenario is divided into steps. For each step, the Actors — the main stakeholders: the supplier and the agencies FMV and FM (together with their business roles) — who execute the scenario; their interactions; the Business Objects involved; and the corresponding Information Objects (as represented in this library) are listed. The scenario provides a context for the DEXs and describes the various information interfaces between the Actors.

The scenario is intended to answer questions such as:

• Which DEXs and messages are applicable to my business?
• Which DEXs and messages are applicable to my project?
• In my role, which information do I have to acquire in order to support my work?

The process overview describes how FMV and FM conduct their business. As the work progresses, the product description grows. Data is exchanged internally between the various departments of FMV and FM and externally with the supplier (in accordance with FMV DEX Business Information Model and with the help of standardized PLCS DEX messages).

Broadly speaking, the course of events can be summarized as follows:

• Målsättningsarbete ("strategy" work)
• System av systemdesign (system of system design)
• Kravarbete (requirements work)
• Upphandling (procurement)
• Leverantörens design (supplier's design)
• Tillverkning (manufacturing)
• Leverans (delivery)
• Systemöverlämning (handover of system)
• Materielöverlämning (handover of materiel)
• Användning inkl. underhållsproduktion (usage and maintenance production) - informativt steg
• Modifiering (modification) - informativt steg
• Avveckling (decommissioning) - informativt steg

Målsättningsarbetet inleds med Försvarsmakten i egen regi eller med stöd av FMV formulerar förmågekrav och operativa förutsättningar för sitt materiella behov i en systemmålsättning (SMS). Utgående från SMS och vilka systemelement som behövs för att realisera den kravställda förmågan formuleras vid överlämningsberedningen en eller flera (om olika krav på olika systemelement) Kravelementlistor (KEL) som kravställer informationsleveranser från FMV till FM. Genom analys av SMS identifieras de funktioner som ett eller flera systemelement ska realisera. Arbetet med att klarlägga vilka funktioner som behövs sker iterativt och parallellt med att definiera systemelement som ska realisera dessa funktioner.

Table 1 -Målsättningsarbete

Utifrån klarlagt behov av funktioner definieras systemelement som ska realisera dessa funktioner. Arbetet med att definiera de systemelement som ska realisera dessa funktioner sker iterativt och parallellt med att klarlägga vilka funktioner som dessa systemelement ska realisera. Succesivt byggs därmed den hierarkin av funktioner och systemelement upp. För varje systemelement definieras systemkrav utgående från förmågekraven vilka hålls samman av en systemdefinition (SYD) med tillhörande Kravsammanställning (KSS). För de definierade systemelementen tas förrådsbeteckning (Fbet) ut.

Table 2 -System av systemdesign

När nedbrytningen av systemelement gjorts till en nivå där utveckling/tillverkning/upphandling bedöms vara lämplig etableras ett ”materielrealiseringsprojekt”. Projektet omarbetar systemkraven till tekniska krav för användning i en upphandling. Förutom systemkraven som fokuserar på systemets funktion tillkommer tekniska krav avseende systemsäkerhet, miljö, användbarhet, m.m. DE tekniska kraven sammanställs i en teknisk specifikation (TS), som tillsammans med en verksamhetsåtagandespecifikation (VÅS) ställer krav på leverantörens verksamhet, inklusive datautbytet med FMV. Om upphandling sker av samverkande delsystem parallellt bryts gränsytekrav ut ur TS:en och sammanställs i en gränsytespecifikation (GYS) som används i båda upphandlingarna för att säkerställa samfunktion. Beroende på typ av underhållslösning formuleras även ett förslag till avtal för leverantörsstött underhåll (CLS).

Table 3 -Kravarbete

Det tekniska anskaffningsunderlaget används i upphandlingen och ett avtal/kontrakt tecknas med en leverantör. I enlighet med VÅS:en översänds TS, GYS, nedre noder i funktions- och systemnedbrytningen, samt information om eventuell tillhandahållen utrustning som ska kunna integreras med den materiel som kravställts. Informationen sänds till leverantören i ett inläsningsbart format (XML eller Excel).

Table 4 -Upphandling

Övergripnade designunderlag tas fram i form av bla systembeskrivning, funktionsnedbrytning, systemnedbrytning och funktionsnedbrytning baserat på teknisk upphandlingsunderlag. Efter godkännande genomförs detaljerad design med framtagning av tillverkningsunderlag och informationsprodukter på typnivå.

Table 5 -Leverantörens design

Produktion av produkter sker i omfattning enligt leverantörskontrakt och de underlag som definierats i designfasen. Systemsäkerhetsunderlag tas fram och verifieringsunderlag sammanställs.

Table 6 -Tillverkning

Indviddata för producerade produkter sammanställs med tillhörande avvikelser och leveransmeddelande upprättas inför leverans.

Table 7 -Leverans

Integration, verifiering och validering sker av olika produkter kopplats till tidigare systemnedbrytningar. Utifrån informationsprodukter upprättas överlämningsbevis och beslut om användning tas.

Table 8 -Systemöverlämning

Orderunderlag upprättas inför materielleverans och för att möjliggöra godsmottagning i redovisande system.

Table 9 -Materielöverlämning

Table 10 -Användning inkl. underhållsproduktion (informativt steg)

Table 11 -Modifiering (informativt steg)

Table 12 -Avveckling (informativt steg)

All example data provided within the DEX:s in the Swedish Defence context are based on a coherent scenario. The scenario within which the example data is explained has the following scope;

A newly started organization decides in 2013 to conduct parcel delivery in a small Swedish city. After formulating the operational need in a system objective specification (SMS), completing the system design and the definition of requirements, the necessary equipment was procured along with the associated maintenance solution. The suppliers appointed for each subsystem performs design activities in accordance with the required business commitment (VÅS) to develop equipment in accordance with the specified technical requirements. When the equipment and its associated information has been received, integration and verification of the complete system is carried out. Following a basic training of the members of the production department, operations begin. Soon the need for both preventive and corrective maintenance arises. The maintenance is executed both using internal resources, as well as with the support of external suppliers. The operation and performed maintenance is continuously documented. After a while, the business need changes, which leads to the development department carrying out a renewed system engineering effort, revised requirements and an engineering change order regarding modification of parts of the stock. This also leads to the retirement of certain parts.

The scenario is currently only available in Swedish and not a part of PLCSlib.

• DataRestrictions
• DeliverySpecification
• FaultDefinition
• FunctionalStructure
• ItemDefinition
• ItemDefinitionBasicData
• ItemIndividual
• MaintenanceReport
• MaintenanceScheme
• OperationalData
• PhysicalStructure
• Requirement
• SystemStructure
• TaskMethod
• TechnicalPublication
• ZoneStructure

• ActualOperatingMode
• AllowedValue
• AmmunitionInformation
• BinaryValueFile
• CalendarBasedSchemeEntry
• Competence
• CompetenceRequired
• DeliveryContent
• DeliveryItemWrapper
• DimensionInformation
• Document
• ECLicenceApplicablity
• ECUInformation
• ExportControlLicence
• ExternalActor
• FacilityDefinition
• FacilityRequired
• FailureOccurrence
• FaultCode
• FaultEffectDefinition
• FaultModeDefinition
• FunctionalBreakdown
• FunctionalElement
• HealthAndEnvironmentInformation
• IPRApplicability
• IdentifyingInformation
• IndividualCertificate
• InfoElementInPublication
• InformationElement
• InformationRequired
• InstalledSoftware
• IntellectualPropertyRight
• InterfaceConnector
• InterfaceSpecification
• Interval
• ItemDefinition
• ItemDefinitionBasicDataContent
• ItemDefinitionStructure
• ItemIndividual
• ItemOfSupplyDefinition
• ItemOfSupplyDefinitionBasicData
• ItemOfSupplyDefinitionStructure
• ItemQuantity
• ItemRequired
• MaintenanceOrder
• MaintenanceScheme
• MeasuredValue
• MessageDataRestrictions
• MessageDeliverySpecification
• MessageFaultDefinition
• MessageFunctionalStructure
• MessageItemDefinition
• MessageItemDefinitionBasicData
• MessageItemDefinitionProductVariant
• MessageItemDefinitionStructure
• MessageItemIndividual
• MessageKitDefinition
• MessageMaintenanceReport
• MessageMaintenanceScheme
• MessageMeter
• MessageOperationalData
• MessagePhysicalDesignStructure
• MessagePhysicalMaintenanceStructure
• MessageRequirementFulfilment
• MessageRequirementSpecification
• MessageSystemStructure
• MessageTaskMethod
• MessageTechnicalPublication
• MessageWrapper
• MessageZoneStructure
• MeterBasedSchemeEntry
• MeterIndividual
• MeterInformation
• MeterReading
• MeterReadingActivity
• MonitoringTerm
• Mounting
• OperatingMode
• OperationalPropertyDefinition
• PartDefinition
• PartDefinitionStructure
• PerformedMaintenance
• PhysicalBreakdown
• PhysicalElement
• PhysicalElementStructure
• PhysicalMeterElement
• ProductConfiguration
• PropertyValue
• Publication
• PublicationStructure
• ReferenceData
• Requirement
• RequirementBreakdown
• SchemeDecomposition
• SchemeEntry
• SecurityClassification
• Software
• SystemBreakdown
• SystemElement
• TaskMethod
• TaskMethodDependency
• TaskMethodStructure
• TermApplicability
• TermValue
• TransportAndStorageInformation
• UsageRestrictionDefinition
• ValidElementRealization
• WarrantedItem
• WarrantyDefinition
• ZoneBreakdown
• ZoneElement

• http://plcs.fmv.se/rd/SwedishDefence-rdl-sv/SwedishDefence-sv.owl

If data exchange scenarios are to be supported for which additional reference data is required, then new OWL ontologies should be created that import from http://plcs.fmv.se/rd/SwedishDefence-rdl-sv/SwedishDefence-sv.owl. The new OWL ontologies then becomes Reference Data Library used by the DEXs.

• http://plcs.fmv.se/rd/SwedishDefence-ItemDefinitionBasicData-sv/SwedishDefence-ItemDefinitionBasicData-sv.owl
• http://plcs.fmv.se/rd/SwedishDefence-rdl-en/SwedishDefence-en.owl
• http://plcs.fmv.se/rd/SwedishDefence-rdl-sv/SwedishDefence-sv.owl

• http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/plcs/plcs-psm/refdata/plcs-psm/plcs-psm-en.owl
• http://docs.oasis-open.org/plcs/ns/plcslib/v1.1/data/contexts/OASIS/refdata/plcs-rdl-dmou/plcs-rdl-dmou-v1_1.owl
• http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/contexts/OASIS/refdata/plcs-rdl-dmou/plcs-rdl-dmou.owl
• http://docs.oasis-open.org/plcs/ns/plcslib/v1.1/data/contexts/OASIS/refdata/plcs-rdl/plcs-rdl-en-v1_1.owl
• http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/contexts/OASIS/refdata/plcs-rdl/plcs-rdl-en.owl
• http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/contexts/OASIS/refdata/plcs-rdl-sv/plcs-rdl-sv.owl