Transcript Terminology

Terminology
For Electronic Data Sheets
Content
This discussion is divided into three
parts.
1.Scope of Dictionary of
Terms
2.Usage of Terms
3.Sample Items for Dictionary
• Application
• Application
support
• Transport
• Network
• Link
• Physical
Reaction wheel
• Application
• Link
• Physical
On-board computer
The dictionary of terms for electronic
data sheets covers a limited domain of
knowledge.
The domain of knowledge is the set of
interfaces between components of
data systems.
1. SOIS interfaces extend through
the layers of a protocol stack.
2. Interfaces cover the diversity of
data system components that
communicate with one another.
3. Electronic data sheets span the
range of volatility of data.
4. Three categories of concepts
could be housed in the dictionary
of terms.
Star tracker
1. Scope
Dimensions Surveyed Here
• Protocol Stack
• Data System Components
• Volatility
• Categories of Concepts
• Application
• Link
• Physical
1.1 Survey of Protocol
Dimension
•
•
•
•
Layers closer to the physical layer
are usually well-defined, so terms
relevant to these layers usually
identify the protocol.
Layers closer to the application
layer tend to vary from device to
device, so terms in the dictionary
must enable electronic data sheets
to describe data that flows
through an interface in a way that
is reusable from mission to
mission.
Standard interfaces can be
established at the application layer
by virtualizing the fundamental
data and services of components.
DVS does this.
Non-standard interfaces can be
supported at any layer.
OBC
RW
Application
Application
Application
support
Transport
Network
Link
Link
Physical
Physical
1.2 Survey of Data System
Component Diversity
•
•
•
•
SOIS data system components are
strictly devices, including
virtualized interfaces.
NASA and AFRL data system
components include both devices
and applications attached to a
software bus.
Both definitions of data system
components use approximately
the same set of terms.
The set of devices includes sensors
and actuators.
•
•
•
Sensors typically publish
measured data, and accept
configuration requests.
Actuators typically accept data
to be realized physically, and
accept configuration requests.
The set of applications includes
control systems, transformations,
and mission schedulers. This
presentation takes no examples
from the set of applications.
Sensors
Devices
Actuators
Data System
Components
Controllers
Applications
Transformations
Schedulers
1.3 Survey of Volatility of
Data
•
•
•
•
•
Volatility in this document refers to the operational
frequency of refreshing an item of data. Highly
volatile data must be examined or published more
frequently than less volatile data.
The typical data that flows across the communication
network of a vehicle is highly volatile. Data from
sensors and commands to actuators must be
refreshed frequently in order to maintain adequate
control of a vehicle.
The data that defines a component, such as size,
mass, maximum current, and thermal limits, might
remain constant for the life of the component. Such
data may be delivered to designers from
manufacturers through a section of an electronic data
sheet.
The data that defines the mounting of a device in a
vehicle, such as location and orientation, remains
constant for many devices during a mission. Such
data may be delivered to flight software from
designers through a vehicle manifest file.
Intermediate levels of volatility still require
refreshment, and so must be delivered through an
interface of the component during flight.
Static in EDS
or in vehicle
manifest
Mission
operations
data
Launch
vehicle
control data
1.4 Survey of Categories of
Concepts
The information in electronic data
sheets that can be standardized
resembles the three aspects of
relational tables.
• The definition of the columns of a
relational table corresponds to the
definition of terms for attributes of
data items in EDS’s.
• The rows of a relational table
correspond to the definitions of
semantic types of variables in
EDS’s.
• An instance of a relational table
corresponds to a description of an
interface in an EDS.
These three categories of objects
define three sections of the dictionary
of terms:
• standard terms
• standard semantic types
• standard interfaces.
term
Ref.
To
Coord
Frame Frame Type
ECI
ECI
device quater
nion
Unit
Name
attitude
Vector Rad/s angRate
EDS
interface
semantic
type
2. Usage of Terms
The purpose of defining terms in the
dictionary is to enable people to use
them accurately and repeatably.
1.Usage of Metadata in SOIS
2.Descriptive Dimensions
3.Recursive Descriptions
4.Static Data in Electronic
Data Sheets
5.Static Data in Vehicle
Manifest
6.Definition of a Variable
7.The Description as the
Name
8.How to Agree on Terms
2.1 Usage of Metadata in
SOIS
•
•
•
•
•
•
•
•
The set of abstract addresses for a
vehicle appears in the vehicle
manifest (VM).
DVS virtual device interfaces are
described by electronic data sheets
(EDS’s).
The initial mapping between DVS
virtual devices and DAS actual
devices appears in the VM.
The DAS maps of device variables are
copies of the device data interfaces
in the EDS’s for the actual devices on
board.
The initial mapping between DAS
addresses and spacecraft network
addresses appears in the VM, with
dynamically-acquired spacecraft
network addresses filled in by DES.
The packet or memory access service
(PMAS) maps of device messages and
interfaces is copied from the EDS’s
for the devices on board.
The subnetwork-specific addresses
used by PAS or MAS come from the
VM and from DES.
The protocols used by PMAS come
from EDS’s for the devices on board.
User Application
Virtual Device Identifier
Device
Virtual
Virtualization
EDS’s
Service
Physical Device Identifier
Device Access
Service
Spacecraft Network Address
Packet or
Actual
Memory Access
EDS’s
Service
Subnetwork-Specific Address
SubnetworkSpecific Protocol
Hardware
Device
DES
Vehicle
Manifest
2.2 Descriptive
Dimensions
•
•
•
The terms that describe data do so
by identifying dimensions and values.
A dimension is a space of mutually
exclusive values.
Example:
•
•
•
“precision” represents the
stochastic variance in a data value
that results from the design and
manufacture of the component that
publishes the data.
The domain of values for precision is
the set of non-negative rational
numbers.
Example:
•
•
•
precision
“reference frame” identifies the
coordinate system in which a
measurement applies
The domain of values for reference
frame is an enumeration that
includes device, vehicle, ECI, and
others.
The definition of a term states
whether it names a dimension or is a
member of the enumeration of a
particular dimension.
non-negative
rationals
device
vehicle
reference
frame
ECI
et cetera
2.3 Recursive Description
The data in electronic data sheets
includes the following levels of
recursive description.
• No recursion, direct description:
data with static volatility. E.g., the
rotational inertia of a reaction
wheel.
• Meta data: defines properties of
the direct data. E.g., the precision
of the nominal rotational inertia of
a reaction wheel.
• Meta meta data: properties of
meta data. Distinguishing this
level and deeper levels of
recursion is unnecessary.
A term defined in the dictionary is
used as meta data.
An value of a data item delivered in
DAS is direct data.
A static data value presented in an EDS
or vehicle manifest is direct data.
Meta meta?
Meta (EDS)
Direct
(message
instances)
2.4 Static Data in an
Electronic Data Sheet
•
•
•
•
Static data appears in an electronic
data sheet as a “Direct” section.
The “Direct” section is a peer with
the definitions of interfaces.
Equivalently, the “Direct” section is
an interface without messages or
protocols.
The variables in the “Direct” section
have values, in addition to their
metadata.
some examples of static data that
might appear in an EDS:
•
•
•
•
•
•
•
•
Size
shape
Mass
Inertia tensor
Center of mass
Direction of optical axis in device
coordinates
Locations of thermistors in device
coordinates
The examples above do not apply to
all devices. For example, a fuel tank’s
mass properties are likely to change
during flight.
Direct
EDS
Variables
with values
Variables
Interfaces
Messages
Protocols
2.5 Static Data in a Vehicle
Manifest
•
•
•
Static data that results from the
design and construction of a
vehicle appears in a file called the
“vehicle manifest”.
The vehicle manifest contains
variables with values, like the
“Direct” section of an EDS.
Some examples of static data that
might appear in a vehicle manifest:
•
•
•
•
Serial number of device
Location of origin of device
coordinate system in vehicle
coordinates
Rotation from device coordinates
to vehicle coordinates, which
defines the orientation of the
device
The examples above do not apply
to all devices. For example, the
location and orientation of a
device whose mount is articulated
is likely to change during flight.
Vehicle
Manifest
Variables
with values
A Sample Variable in a Star Tracker
(from SAVOIR-SAFI)
2.6 Definition of a Variable
The following information appears in
an electronic data sheet to define a
variable. The text at right is an
example, in an arbitrary syntax.
• name
• description
• type
• unitOfMeasure
• coordinateType
• referenceFrame
• toFrame
• variance
• purpose
– name =
“FinalAttitudeQuaternion”
– description=“the direction that
the optical axis is pointing, and
the rotation of the device around
that axis”
– type = “float32”
– unitOfMeasure is not applicable,
so it does not appear
– coordinateType = “Quaternion”
– referenceFrame = “J2000”
– toFrame = “device”
– variance = “0.002”
– purpose = “measurement”
• Variable described by attributes
2.7 The Description as the
Name
•
•
•
•
Name with attributes, URI style
The example shows a tuple in
description space defined by
referenceFrame, toFrame,
purpose, coordinateType.
A syntax similar to this has been
proposed at AFRL, but not yet
used in real EDS’s.
This style of names could serve to
name the standard semantic types
of variables.
– name = “attitude”
– description=“the direction that the optical
axis is pointing, and the rotation of the
device around that axis”
– type = “float32”
– coordinateType = “Quaternion”
– referenceFrame = “ECI”
– toFrame = “device”
– variance = “0.002”
– purpose = “measurement”
• Variable in URI style
– name = “attitude”
– semantic type= “ECI.device.measurement.
Quaternion”
– description=“the direction that the optical
axis is pointing, and the rotation of the
device around that axis”
– encoding=“float32”
– Variance=“0.002”
2.8 How to Agree on
Terms
•
•
Agreement on terms is sometimes
difficult.
One cause of the difficulty is the
variety of contexts in which people
use terms.
•
•
•
Example: We use green, yellow
and red to represent severity of
alarms. Let’s put this into
electronic data sheets. Now I try
to use one of these data sheets,
and I find that the alarm criteria
are not right for my mission. The
problem is that these alarm
settings are not a property of the
component, but of the mission.
The context of usage of terms for
this dictionary is writing and
reading electronic data sheets to
describe spacecraft components.
Terms cannot be accepted into the
dictionary without a successful
demonstration of their use in
writing and reading electronic data
sheets.
Propose a
term.
Use the
term to
write EDS’s
Try to use
the EDS’s.
Accept the
term.
3. Sample Items for
Dictionary
This section populates the three
sections of the dictionary with sample
items.
1. Terms
2. Standard semantic types
3. Standard interfaces
3.1 Terms
This section offers a sample of terms
for discussion. Some of these samples
are competing proposals.
1. Template for Defining a Term
2. purpose
3. type (API)
4. encoding (XTCE)
5. array Length
6. reference Frame
7. coordinate system
8. unit of measure
9. coordinate type
10.quaternion
11.subject
12.Star Tracker Mode
3.1.1 Template for
Defining a Term
The following information appears in
the dictionary to define a term. The
diagram on the right is an example.
• Name: The name of a term is the
name of a concept, so it may
contain multiple words. See Usage
below.
• Description: This string is for use
by human engineers.
• Range:
•
•
•
•
•
If a term is a dimension, then this
parameter is an interval or an
enumeration.
If a term is an enumeration
value, then it has no “Range”.
Usage in EDS: The actual encoding
of the name in syntax appears in
this section.
Use Cases
Acceptance
Name
Reference Frame
Description
…
device
J2000
Range
…
Definition of
term
vehicle
Usage in EDS
referenceFrame
attribute of
Variable
Convert sensor
data to vehicle
coordinates.
Use Cases
Convert torque
to actuator
coordinates.
Acceptance
Proposed
3.1.2 Purpose
•
•
•
Description: how to apply a
variable.
Range: See enumeration diagram
at right.
Usage in EDS: purpose attribute of
•
•
•
a variable
a variable reference in published
data or in a command
Use Cases:
•
•
•
•
•
Nominal
Distinguish a set point from a
measurement to be controlled.
Distinguish a central value from
an actual value.
Distinguish an adjustment from a
measurement.
Note that the purpose is not
always a property of a variable,
but frequently derives from its
context of usage, such as
command or published data.
Acceptance: proposed
Measurement
Purpose
SetPoint
Calibration
bit
int8
3.1.3 Type (API)
•
•
•
•
•
•
•
The set may be larger than the actual range of the
variable, but not smaller.
This concept is equivalent to a “type” of a
primitive data element in a programming
language.
See the coordinate type definition for an extension
to this meaning.
Range: See enumeration diagram at right.
Usage in EDS: type attribute of a variable
Use Cases:
•
•
•
•
int16
Description: The type names a subset of the
rational numbers that is appropriate to represent
the value of a variable when the variable is
serialized for transmission.
Establish the number of bits that the variable
occupies when transmitted.
Identify a standard interpretation of the bits in the
transmitted form of the variable.
In order to support both API and messaging
interfaces, the order of bits is not determined by
Type; rather, the machine order or the network
order determines the physical order of bits.
Acceptance: proposed, but an alternative is the
abstraction offered by XTCE.
int32
int64
Type
uint8
uint16
uint32
uint64
float32
float64
binary
IEEE754_1985
3.1.4 encoding (XTCE)
•
Description: The encoding names a
convention for encoding data, taken from
XTCE.
•
•
•
•
•
•
•
The error detection, bit order, and byte order
are omitted here, in order to be specified
separately for different media. The machine
order or the network order determines the
physical order of bits and bytes.
The calibration of floats is omitted here, to be
specified separately.
The transform algorithm for binary data is
omitted here, to be specified separately.
The string encoding is omitted here, to be
specified separately as an aggregate data type.
Range: See enumeration diagrams at right.
Usage in EDS: encoding attribute of a variable
Use Cases:
•
•
•
float
Establish the number of bits that the variable
occupies in the interface.
Identify a standard interpretation of the bits in
the interface.
Acceptance: proposed, but an alternative is
the type attribute typical of programming
languages.
MILSTD_1750A
Encoding
unsigned
signMagnitude
twosCompliment
integer
onesCompliment
sizeInBits
[1, maxint]
BCD
packedBCD
3.1.5 Array Length
•
Description: The array length
specifies the number of elements
in an array of elements which,
taken as a whole, constitutes a
variable.
•
•
•
•
•
•
Range: See enumeration diagram
at right.
Usage in EDS: length attribute of a
variable
Use Cases:
•
•
Arrays may represent vectors or
multi-dimensional matrices.
The elements of an array are all
of the same type, specified by
the Type property of the variable.
The order of elements in a
multidimensional array places
the elements of the first stated
dimension adjacent to one
another.
State the size of a list of data
elements that are all of the same
type.
Acceptance: proposed
n
Array
Length
(n, n)
(n, …, n)
Device
3.1.6 Reference Frame
•
•
•
•
Description: the frame of
reference in which a variable is
relevant.
Range: See enumeration diagram
at right.
Usage in EDS: referenceFrame
attribute of a variable
Use Cases:
•
•
•
Determine the frame in which a
variable is represented, in order
to determine what
transformation is needed to
represent the variable in the
frame appropriate to an
application.
Determine the frame of
reference that is input to a
transformation of coordinates,
when the toFrame attribute is
also present.
Acceptance: proposed
ECEF
ECI
Reference
Frame
LVLH
Mount
Transducer
Vehicle
External
Object
3.1.7 Coordinate System
•
•
•
•
Description: the convention for
interpreting the coordinates of a
variable.
Range: See enumeration diagram
at right.
Usage in EDS: coordinateSystem
attribute of a variable
Use Cases:
•
•
Cartesian
coordinateSystem
Spherical
Distinguish angular and linear
coordinates.
Acceptance: proposed
Cylindrical
m^em
kg^ek
3.1.8 Unit of Measure
•
Description: the units of measure
of a variable.
•
•
•
•
•
•
Range: The range is the set of
products of powers of SI base units
and other units outside SI base
units. The value “none” is also in
the range.
Usage in EDS: unit attribute of a
variable
Use Cases:
•
•
For units based on SI base units,
the style resembles that in IEEE
1453 TEDS.
For units that would be 1 by the
scheme above, a formal name is
used, such as “radian”.
For unitless numbers, such as
DCM elements, “none” is used.
Distinguish position and velocity
vectors.
Acceptance: proposed
s^es
A^eA
Unit of
Measure
K^eK
mol^emol
cd^ecd
radian
none
…
J2000
MOD (mean of
date)
3.1.9 Coordinate Type
•
Description: how to interpret a variable that is a
list of coordinates.
•
•
Multi-coordinate variables may represent vectors
in a particular coordinate system or a
transformation between coordinate systems.
The Coordinate Type identifies a particular
combination of the following terms:
•
•
•
•
•
•
•
•
•
•
•
•
Coordinate System
Unit of Measure
Reference Frame
To Frame
Array Length
Some of the terms listed above may be
incompletely determined by a coordinate type,
and so must be specified with coordinate type.
Those terms above that are completely
determined by a coordinate type need not be
specified with that coordinate type.
The definition of the coordinate type term must
provide the information above, and identify
ambiguities.
Range: See enumeration diagram at right.
Usage in EDS: coordinateType attribute of a
variable
Use Cases:
•
TOD (true of
date)
Interpret a variable with multiple coordinates.
LatLon
LLA (latitude,
longitude,
altitude)
Coordinate Type
UPS (universal
polar
stereographic)
UTM (universal
transverse
mercator)
Quaternion
RollPitchYaw
Acceptance: proposed
…
3.1.10 Quaternion
•
Description: The four coordinates
are a scalar value first, followed by
three vector coordinates,
corresponding to the orthogonal
right-handed Cartesian coordinate
axes x, y, and z. A quaternion is
typically used as a rotation which
transforms from “referenceFrame”
to “toFrame”.
•
•
•
•
•
•
•
Usage in EDS: coordinateType =
“Quaternion” attribute of a
variable
Use Cases:
•
•
Coordinate System: Cartesian
Unit of Measure: none
Reference Frame: specify
To Frame: specify
Array Length: 4
Identify the convention for the
coordinates of a quaternion
variable.
Acceptance: proposed
coordinateType
Quaternion
Device
3.1.11 Subject
•
•
•
•
Description: The subject of a
variable identifies an object for
which the variable is a property.
Range: See enumeration diagram
at right. This enumeration
resembles that of reference frame,
but actually overlaps only for
objects that have their own
reference frame.
Usage in EDS: subject attribute of a
variable
Use Cases:
•
•
Distinguish the location of a
target on Earth from the location
of the nadir point of the
spacecraft.
Earth
Transducer
Subject
Nadir Point
Vehicle
Acceptance: proposed
Image
Target
command
startup
3.1.12 Star Tracker Mode
•
•
•
•
Description: the operating mode
of a star tracker
Range: See enumeration diagram
at right. These values come from a
simulated star tracker. The ETSI
SSDHI document lists only tracking
and lost in space.
Usage in EDS: StarTrackerMode
enumeration in range of variables
that represent the mode of a star
tracker
Use Cases:
•
•
•
•
Determine the next step in
operating a star tracker,
according to a finite state
machine.
Determine whether the attitude
data produced by a star tracker is
valid.
Command a star tracker to reset.
Acceptance: proposed
lost in
space
image
Star Tracker
Mode
tune
gain
integration
time
image size
tracking
3.2 Standard Semantic
Types
A sample of standard semantic types
appears at right for discussion.
1.ECI.device.measurement.
Quaternion
2.ECI.rad/s.measurement.An
gularRate
3.Measurement.StarTracker
Mode
4.SetPoint.StarTrackerMode
3.3 Standard Interfaces
A sample of standard interfaces
appears at right for discussion.
1.CoarseSunSensor
2.Magnetometer
3.DevicePower
3.3.1 CoarseSunSensor
This interface is simple, because the
device that it represents simply
provides a measure of light intensity.
SunSensor
Status
Intensity
3.3.1 CoarseSunSensor
This interface represents a
magnetometer function.
The “NumberOfAxes” variable
provides a static value that does not
change during a mission.
SamplingRate
DataRate
ScaleFactor
Magnetometer
Polarity
MinimumTemperature
Status
MaximumTemperature
Temperature
NumberOfAxes
Sensitivity
FieldStrengthArray
3.3.1 DevicePower
This interface is typical in SPA xTEDS,
where a small processor presents each
device on the network, with the
capability to turn power on and off for
the device.
PowerState
DevicePower
Status
PowerReset
ResetReason