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
Gary.Mayer@FlatIronsSolutions.com
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
-ApprovalS1000D

<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

More Related Content

Similar to Spec 2300 Common and Unique Design Features

More from Flatirons Solutions®

Recently uploaded

Spec 2300 Common and Unique Design Features