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

Recommended

Recommended

More Related Content

Similar to Spec 2300 Common and Unique Design Features

Similar to Spec 2300 Common and Unique Design Features (20)

More from Flatirons Solutions®

More from Flatirons Solutions® (8)

Recently uploaded

Recently uploaded (20)

Spec 2300 Common and Unique Design Features