spec 2300 common and unique design features

©2014 Flatirons Solutions, Inc. All rights reserved.

Spec 2300:

Common and Unique

Design Features

Gary Mayer

Flatirons Solutions, Inc.

TS/X S1000D

Chief Architect

[email protected]

ATA e-Business Forum and

S1000D User Forum

June 2014 San Antonio, Texas, USA


Agenda

Spec 2300 resources

Module structure: combined vs. separate metadata and content

Applicability: understanding and using this very general model


Spec 2300 resources


Documents assembled from three kinds of objects: Publication Modules: PM

•for organizational/structural parts •chapter, section, subject levels •titles, but no other content

Data Modules: DM •for actual content •procedures, checklists, limitations, etc. •text, tables, graphics

Media Resources: ICN •Pictures, illustrations and charts •Multimedia – 3D models/animations, video

Spec 2300 resources


Publication Modules [PM] • TOC defining hierarchal organization for data modules • Very close to S1000D Publication Modules • Build a hierarchy like chapter, section, subject in iSpec 2200 • Titles and links, but no other content

Publication Modules

PM


<pmEntry pmEntryType="Document">

<title>Dispatch Deviations Guide (DDG)</title>

<pmEntry pmEntryCode="0" pmEntryType="Section">

<title>Preface</title>

<dmRef>

<dmRefIdent>

<dmCode modelIdentCode="ABBE2300" systemDiffCode="A"

systemCode="00" su

<language countryIsoCode="US" languageIsoCode="en"/>

</dmRefIdent>

. . .

<pmEntry pmEntryCode="2" pmEntryType="Section">

<title>Master Minimum Equipment List</title>

<pmEntry pmEntryCode="0" pmEntryType="Chapter">

<title>Preamble</title>

<dmRef>

<dmRefIdent>

<dmCode modelIdentCode="ABBE2300" systemDiffCode="A"

systemCode="00" s


</dmRefIdent>

</dmRef>

</pmEntry>

<pmEntry pmEntryCode="21" pmEntryType="Chapter">

<title>ATA 21 - Air Conditioning</title>

<dmRef>

Publication Modules

Data Modules [DM] – the real content with many types:

Approval, Dispatch, Limitations, NonNormalProcedure, NormalProcedure, Performance, Substantiation, SystemDescription. . .

DataModules



<dispatchItem numberInstalled="1" optionalConfigurationIndicator="true">

<title>Autopilot system</title>

<placard>



<para>Put an AUTOPILOT SYSTEM INOPERATIVE placard on the FLIGHT CONTROL panel.</para>

</placard>

<dispatchCondition repairInterval="C">

<normalDispatchCondition numberRequired="0">

<remark>

<proviso>

<para>Except where enroute operations or approach procedures required its use,

may be inoperative provided Altitude Alerting System is operative.</para>

<note>

<para>Autopilot is required for <abbreviation glossaryItemId="RVSM"/>

operations.</para>

</note>

</proviso>

</remark>

</normalDispatchCondition></dispatchCondition></dispatchItem>


Module structure

Combined vs. separate metadata and content


Publication and Data modules are comprised of two tightly bound XML documents:

•Linked by having the same “name” •Status: metadata for the data module

•Name (PMC or DMC) •Issue •Variety of metadata like Approval

•Content: the actual XML content that you expect

•Name (PMC or DMC) •Issue •Content (no rev markup, no applicability, etc.)

Separate XML metadata and content documents

2300 DM Status -Name -Issue -Approval ...

2300 DM Content -Name -Issue ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(( ))

Content

~~~~~~~~~~~~~~~

S1000D DM Status -Name -Issue -Approval S1000D



<dmStatus dataProducer="oem" issueType="new"

<dmIdent>

<dmCode modelIdentCode="ABBE2300" systemDiffCode="A" systemCode="22" subSystemCode="1" subSubSystemCode="2" dispatchItemExtensionCode="010-0000-000"

assyCode="01" disassyCode="01" disassyCodeVariant="A" infoCode="12C" infoCodeVariant="A" itemLocationCode="A"/>


</dmIdent>

<issueInfo issueDate="2013-12-25T09:30"/>

<dmContentIssueInfo issueDate="2013-12-25T09:30"/>

<approvalInfo approvalRequired="yes"/>

<applicCrossRefTableRef ...

<applic id="app-001"> <assert applicPropertyIdent="lineNbr"

<inlineApplicGroup

<inlineApplic path=“/dmodule/content/dispatchItem/dispatchCondition[2]”

<assert applicPropertyIdent="lineNbr" applicPropertyType="prodattr“

<reasonForUpdate id=“A123456”><para>Correct error on the condition

<contentRevisions>

<change changeType="modify" reasonForUpdateRefIds=“A123456” path=“/dmodule/content/dispatchItem/dispatchCondition[2]”

</dmStatus>

Applicability of the

content module

Applicabilities

for parts of the

content

Identifies

changed parts

of the content



Status: Has both status and content info

Applicability

Reason for update

Content revision markers Use xpaths to point into the

relevant parts of the content XML module

Content: Remains “pure”

Has no rev markup, no applicability, etc.

Rendering requires both for filtering, revision markup

DM Content

DM Status

~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~

Applicable to N345D Applicable to N345D ... Revised per SB-1234



New paradigm

Unique approach

Not in iSpec 2200 or S1000D

Systems development needed to create or import

Supports changing applicability via status module without changing/redelivering content module

Exchange Standard

Data may be delivered as Spec 2300

EFB’s may require Spec 2300

Internally an OEM’s or operator’s system may manage the data is a different way


Applicability

Understanding and using this very general model


Applicability

MODEL TAIL LINENO SERNO SB-1234 SB-5678 EO-AN5

940-20 N123D 25914 123456 PRE POST INC

940-20 N124D 25741 123457 POST POST INC

940-20 N125D 14891 123458 POST PRE INC

940-30 N210D 19471 148966 POST INC

940-30 N211D 89174 148953 POST NON

940-40 N400D 59174 150100 POST INC

940-40 N401D 89471 150101 PRE NON

Applicability Cross-reference Table

ACT: Static characteristic columns

Applicability table defined via 3 modules Condition Cross-reference Table

CCT: Dynamic config columns

Product Cross-

reference Table

PCT:

Row for each

Product instance

This portion like iSpec 2200 EFFXREF


Basic Building Blocks

ACT: Applicability Cross-reference Table Defines “columns” for persistent product attributes (e.g. msnbr)

CCT: Condition Cross-reference Table Defines types of conditions

Configuration: Service bulletin, EO Situational: Weather (“in icy conditions”), operating region

Define instances of those types (e.g. SB12335) Configuration conditions also define product “columns”

PCT: Product Cross-reference Table Defines product instances in terms of the above Condition state defined here, not in the modules Thus can be updated dynamically with condition (e.g. SB) status

Filtering of Content Select a product instance and all “cell” values used to filter

Query Compose arbitrary logic based on product attributes and/or condition

status


Assert Statement

Purpose is to mark which parts of the document content are applicable to which product instances

Simple language for writing Boolean expressions

Base construct is assert <assert applicPropertyIdent=“TAIL“

applicPropertyType="prodattr“

applicPropertyValues=“N345D|N366D|N412D"/>

Evaluates to TRUE or FALSE

TRUE for aircraft tails N345D, N366D or N412D

FALSE for all others

Allows arbitrary text - always considered TRUE <assert>in icy conditions</assert>


Assert Statement

Simple iSpec 2200 effect

<effect effrg="004099 214265"/>

Spec 2300/S1000D equivalent <applic>

<assert applicPropertyIdent=“cec“

applicPropertyType="prodattr“

applicPropertyValues="004~099|214~265"/>

</applic>

The effrg directly corresponds to the values for the assert

May display as: Applicable to: 004-099 or 214-265


Evaluate Statement

Use Boolean evaluate statements to build more complex

statements: <applic>

<evaluate andOr="and">

<assert applicPropertyIdent="tailNumber"

applicPropertyType="prodattr"

applicPropertyValues=“N345D|N366D|N412D"/> <assert applicPropertyIdent=“SB12345"

applicPropertyType=“condition"

applicPropertyValues=“POST"/> </evaluate>

</applic

Evaluates to TRUE or FALSE This is TRUE for aircraft tails N345D, N366D or N412D

and when SB12345 is POST for the aircraft PCT may indicate if an aircraft is PRE or POST and filter

the content – e.g. filter if it is PRE in this case


Applicability Statements Marking Content Each applic starts with one evaluate or assert

statement

Each evaluate:

Has two or more assert and/or evaluate statements

Can nest to nay depth

Can construct quite complex logical expressions

Precisely define relationships between multiple SBs

Any assert that does not explicitly evaluate to FALSE is considered TRUE

i.e. Hide content only when positively determined


Applicability: Conclusion

Flexible, Highly Configurable Capability

Nearly identical to S1000D applicability scheme

You define all the table columns and what they mean

Applic statements written and evaluated using completely standard methods

Thus behavior is always the same in all systems


Conclusion


Spec 2300 Design: Conclusion

Modular structure similar to S1000D and some OEM flight ops formats

Very detailed flight ops semantics

Some new, novel concepts like separate status and content modules

Some familiar S1000D concepts like applicability

Requires unique system support


Questions

spec 2300 common and unique design features

Technology

content applicability

content xml module content

content data modules

approval content

real content

content documents status

actual xml content

content publication