Systems Engineering Management Plan

System Engineering Management Plan
for
Traffic Management Data Dictionary and Message Sets

for External Traffic Management Center
Communications (TMDD MS/ETMCC)
Version 3.0
An Informational Level Standard

October 13, 2006September 7, 2007
TMDD MS/ETMCC V3 SEMP
Table of Contents
1 Purpose of Document..............................................................................................................1
2 Project Scope...........................................................................................................................1
3 Systems Engineering Process..................................................................................................2
3.1 Systems Engineering Process Overview.........................................................................2
3.2 Concept of Operations.....................................................................................................3
3.3 System Requirements......................................................................................................3
3.4 Design..............................................................................................................................4
3.5 Systems Analysis and Control.........................................................................................6
3.5.1 Risk Management Plan............................................................................................6
3.5.2 Configuration Management Plan...........................................................................11
3.5.3 Verification and Validation Plan:...........................................................................14
3.5.4 Technical Reviews.................................................................................................16
3.5.5 Requirements Traceability.....................................................................................17
4 Applicable Documents...........................................................................................................18
Appendix: 14817 Compliance Related Tables – Preliminary........................................................19
Revision History
Filename Version Date Author Comment
TMDD SEMP-Draftv5.doc 0.00.1 7/14/06 B. Eisenhart Initial Draft
TMDD SEMP-finalv1.doc 0.10 8/15/06 B. Eisenhart Final
TMDD SEMP-finalv1-1.doc 1.0 10/13/0 B. Eisenhart Final- incorporating

6 Mitretek Comments
TMDD SEMP- v1-2.doc 1.2 9/7/07 B. Eisenhart Update at mid project
ii
1 Purpose of Document
This document is a description of the system engineering plan that will be used for the
development of the Traffic Management Data Dictionary (TMDD MS/ETMCC) Version 3.0.
The Systems Engineering Management Plan (SEMP) is the top-level plan for managing the
systems engineering effort. The SEMP defines how the systems engineering portion of the
project will be organized, structured and conducted and how the total engineering process will be
controlled to provide a product that fulfills customer requirements. The SEMP will be used in
technical management of the project. The SEMP outline included in INCOSE SE Handbook,
Version 2a, Appendix C was used as a guide for the development of this SEMP. The format and
content of the SEMP has been tailored to fit the project.
2 Project Scope
The development of TMDD MS/ETMCC V3 will update the current version to incorporate
feedback received from deployments, address additional areas of scope and address issues
unresolved from the earlier version. Specifically the development will address the lessons
learned from a number of deployments (TRANSCOM, TxDOT, FDOT, CARS). The standard
will be extended to include data elements and message sets from the Clarus initiative and the
Archived Data User Service (ADUS) standards effort. In addition, the effort will update the data
dictionary meta data to conform to the ISO 14817 standard (which replaced the IEEE 1488 and
1489 standards that have now been withdrawn). Finally, the effort will address the unresolved
issues from the earlier versions.
The objectives for TMDD MS/ETMCC V3 are:
1. Correct the deficiencies from Version 2.1 as identified in the Mitretek comments
(includes a complete verification and validation effort on all needs, requirements and
design elements in the document).
2. Correct the deficiencies from Version 2.1 as identified in the Generic Reference Model
(GRM) comments.
3. Assess needs, requirements and design element inputs as requested by the Clarus
Initiative and add those needs, requirements and design elements in a manner consistent
with the Systems Engineering Process (SEP).
4. Assess needs, requirements and design element inputs from the CARS states and add
those needs, requirements and design elements selected in a manner consistent with the
SEP.
5. Assess needs, requirements and design element inputs from ADUS and add those needs,
requirements and design elements selected in a manner consistent with the SEP.
6. Assess issues and integrate lessons learned from current deployments, specifically CARS,
TRANSCOM, FDOT and TXDOT into the TMDD MS/ETMCC Concept of Operations
(ConOps), requirements and design.
7. Use an SEP to ensure the completeness and correctness of TMDD MS/ETMCC V3
documents. The standard must be traceable and logically consistent.
8. Develop TMDD MS/ETMCC V3 conformant to ISO 14817.
9. Develop a TMDD MS/ETMCC V3 WSDL/SOAP specific model.
1
10. Develop a detailed conformance statement that addresses backwards compatibility and
provides clear and unambiguous instruction on how to extend the standard.
11. Participation in meetings by the chairman and/or a consultant of the following standard
areas shall be effected: ATIS, TCIP, IM, NTCIP Center-to-Center, ADUS. A
representative from the Clarus Initiative will be asked to attend meetings.
12. Provide a publication-ready TMDD MS/ETMCC V3 standard that fulfills objectives 1-11
above within 23 months from authorization to proceed (ATP) by the Federal Highway
Administration’s (FHWA) Contracts Office.
3 Systems Engineering Process

3.1 Systems Engineering Process Overview
A systems engineering process is a structured way of thinking about and defining a system. The
systems engineering process is an iterative approach to technical management, acquisition and
supply, system design, product realization, and technical evaluation at each level of the system,
beginning at the top (the system level) and propagating those processes through a series of steps
which eventually lead to a preferred system solution. Figure 1 shows a representation of the
systems engineering process called the VEE diagram. This general process has been customized
for use in the development of TMDD MS/ETMCC V3. The focus of this development effort will
be the process steps from the left side of the VEE that are indicated by the oval in Figure 1.
Figure 1: Systems Engineering Process
Due to the nature of this development effort, there is no software coding or hardware fabrication
involved in the final outputs. Nor is there testing per se. The effort will focus on concept of
operations (defined by user needs), system requirements (primarily functional requirements), and
design (both aspects of high level and detailed design). The following sections focus on the
process for performing the system engineering steps that are a part of this project.
2
3.2 Concept of Operations

The purpose of a Concept of Operations is to clearly convey a high-level view of the “system” to
be developed that each stakeholder can understand. This portion of the development effort
identifies the user needs that must be addressed by the standard. The current TMDD V2 1 has two
sections that provide information normally associated with a concept of operations- Section 2
ATMS Concepts for Center-to-Center, and Section 3, Supported Operations. The latter section
covers user needs and is hierarchically organized, beginning with general needs such as “Section
3.3 User Need to Manage Information” and progressing to detailed needs such as Section 3.3.1.1
Need for current event information. The plan for version 3 development is to pull the
information from these two sections into a single section titled Concept of Operations. The
information currently in the standard fits closely into the Concept of Operations outline as
defined in ANSI/AIAA-G-043-1992, and shown in Figure 2.
ANSI/AIAA-G-043 Outline
1. Scope
2. Referenced Documents
3. User-Oriented Operational Description
4. Operational Needs
5. System Overview
6. Operational Environment
7. Support Environment
8. Operational Scenarios
Figure 2: Industry Standard Concept of Operations Outline
The new concept of operations section will reorganize and revise (particularly in the area of user
needs) the material in the referenced sections of TMDD V2. The new concept of operations
section will contain subsections per the above outline except for Referenced Document, System
Overview, and Operational Scenarios. The primary source of user needs update will be a User
Needs Workshop which is planned early in the development effort. The focus of the workshop
will be to gather needs (and associated requirements/ design inputs) from the following groups:
 Archived Data User Service (ADUS) standards effort
 Clarus Initiative
 Deployers of TMDD V2 (e.g CARS, TRANSCOM, TxDOT, and FDOT)
Each group presenting at the workshop has been asked to identify, within the current hierarchy of
user needs, additional or modified needs.
Following the workshop, the full set of user needs (existing plus revisions from the workshop)
will be entered into the Rational RequisitePro requirements traceability tool as a beginning to the
overall tracing of needs to requirements to design (discussed in Section 3.5.5).
3.3 System Requirements

This portion of the development process identifies the functional requirements which the
standard must satisfy in the definition of dialogs, messages, and data elements. As with user
1
V2 used herein is intended to identify TMDD Version 2.1 as formally approved and published by the ITE and
AASHTO.
3
needs, this effort will build upon the requirements developed in V2. The current version of the
standard has requirements hierarchically organized in “Section 4.3 Features”. The plan for
version 3 development is to improve the representation of the current requirements, specifically
to ensure that each requirement is uniquely numbered (to support traceability). The requirements
will be augmented, modified as needed to address the new areas supported by V3 as well as the
lessons learned from deployments. These new/ modified requirements will be initially collected
at the User Needs Workshop described above, augmented by additional written inputs from
deployers. The full set of requirements will be entered into the Rational RequisitePro
requirements traceability tool in order to perform requirements traceability as discussed in
Section 3.5.5.
The process of requirements development will identify that these requirements are complete and
correct. This will make use of the Needs to Requirements Traceability Matrix (NRTM), which is
discussed in more detail in Section 3.5.5. For each requirement (either the existing ones or
newly defined ones) the following criteria will be reviewed:
1. Is it a “good” requirement? Some of the attributes of “good” requirements are:
 Necessary (see bullet 2)
 Clear (unambiguous)
 Complete (see bullet 3)
 Measurable (quantifiable)
 Consistent (with each other)
 Achievable (feasible)
 Testable
 Technology independent
2. Is the requirement mapped to one or more user needs? This will also address
whether the requirement is in fact needed.
3. Does the requirement satisfy the intent and all key items of the need?
3.4 Design
In the context of TMDD MS/EMTCC development, design is the definition of dialogs, messages,
data frames, and data elements. V2 has a set of messages, data frames and data elements
(together known as data concepts) defined. The general approach for updating of an existing
data concept is through the comment resolution process (See section 3.5.3). Newly defined
requirements, however, may develop into new or updated data concepts. The process for defining
new data concepts is to identify what information exchange is required to satisfy some new user
need. For example, a user need such as “Provide New Device Status Information” may result in
new requirements, which could in turn result in new dialogs and messages. To meet the new
requirements, existing data frames and data elements might be re-used (i.e., they already defined
and form parts of existing messages). However, if necessary, new data elements and data frames
(defining a new re-usable portion) can be created.
The TMDD V2 Annexes will be used as the source of the baseline of the TMDD V3 data
concepts. The Annexes contain messages, data frame, and data element definitions of the
TMDD.
4
Backwards Compatibility
One of the objectives of the project is to “develop a detailed conformance statement that
addresses backwards compatibility and provides clear and unambiguous instruction on how to
extend the standard”. To develop the conformance statement this effort will build upon work
done by the NTCIP committee. Their efforts will form a starting point for a definition of
backwards compatibility to be used in the development of TMDD V3. There are distinct
differences between TMDD, which is a center to center information standard, and NTCIP
standards, which are primarily center to field device standards, so the work done by NTCIP will
need to be revised and presented to the TMDD committee for discussion and approval. This
aspect of design will develop a general definition of backward compatibility as related to TMDD
and then provide a detailed set of “guidelines” on how this applies to specific message/ data.
Relation to NTCIP Application Level Standards

The TMDD standards are an Information Level Standard, as defined by the NTCIP Framework.
An Information Level Standard defines the content, syntax, and semantics of exchanges between
center-based systems. An Information Level Standard does not define the mechanism of
encoding and transporting a message between centers – this is defined by Application Level
Standards such as the Application Profiles NTCIP 2304 (AP-DATEX) and NTCIP 2306 (AP-
C2CXML). The AP-DATEX is based on the rules of message encoding and transport of ASN.1,
while the AP-C2CXML is based on the rules of message encoding and transport of the W3C
(World Wide Web Consortium) Web Services Architecture. The NTCIP 2306 also provides a
way to define dialogs, based on the Web Services Definition Language (WSDL).
For the TMDD to be used in conjunction with the application profile standards, the 14817 data
concepts will be defined in an application profile-specific manner. These outputs are listed
below:
Table 1: Summary of TMDD Application Profile Specific Content
Application Profile Data Concept Comment

Description
Method
AP-DATEX ASN.1 14817 provides a general specification of data
(NTCIP 2304) concepts using ASN.1, and specific examples of
ASN.1 representations for data element, data frame,
and message.
AP-C2CXML XML Schema XML Schema is used to define data elements, data
(NTCIP 2306) and WSDL frames, and messages. The SAE-J2630 rules for
translation of ASN.1 to XML will be used to develop
the resulting TMDD XML Schema.
WSDL (Web Services Description Language) will be
used to describe the TMDD Dialogs.
5
Therefore the TMDD V3 shall provide description of data concepts in ASN.1 for compatibility
with AP-DATEX, and in XML Schema (for Data Elements, Data Frames, and Messages), and
WSDL (for Dialogs).
In defining the WSDL dialogs for TMDD V3 the dialog structure laid out by the AP-C2CXML
shall be used. AP-C2CXML supports the following dialog (or messaging) patterns:
 One-way. A concept intended for bulk data transfer, this messaging concept relies on
request of an XML file by its name.
 Request-Response. This message pattern supports the sending of a TMDD messages
followed be a response. This is a typical synchronous pattern of communications.
 Subscription-Publication. This message pattern supports a subscriber application
performing an initial request-response to set up future asynchronous responses from an
information publisher application.
3.5 Systems Analysis and Control

This portion of the SEMP describes the plans that will be put in place to control the development
process.
3.5.1 Risk Management Plan

Risk management is the identification and control of risks associated with the development
effort. The goal of risk management is to identify potential problems before they occur, plan for
their occurrence, and monitor the system development so that early actions can be taken.
Risk management includes the following general steps:

 Risk Identification
 Risk analysis and prioritization
 Risk Mitigation
 Risk Monitoring
The specific risks associated with the TMDD MS/ETMCC V3 development and plan for dealing
with these risks are defined below. The current update of the SEMP at midproject will highlight
some of the risks that have been encountered and update the mitigation efforts taken or underway
to deal with these risks.
3.5.1.1 Risk Identification

The risks associated with the development of TMDD MS/ETMCC V3 standard are affected by
the nature of the development- that this is a major update to an existing standard, not a new
development effort. The following six risk areas have been identified and will be analyzed in the
following section.
Risk area #1: Don’t get correct or complete inputs at the Needs Assessment Workshop.
The development process, as described in the Project Management Plan identifies a Needs
Assessment Workshop, occurring early in the development process, as the primary venue for
6
obtaining new needs/ requirements from the Archived Data standards effort and from the Clarus
Initiative. This meeting will also be the primary input of lessons learned from deployments such
as CARS. The assumption in the project development cycle is that complete and correct inputs
will be obtained from all sources, enabling the development team to proceed with concept of
operations and requirements updates. What if this assumption is not correct-e.g. key
stakeholders do not provide inputs, or provide incomplete inputs. Or what if the effort does not
solicit input from all of the “right” players. This is a risk area that will need to be evaluated and
monitored. .
Risk area #2- New needs (or requirements) come in late in the process
What happens if new needs (or more likely new requirements) are identified after the “final”
needs or requirements have been developed (which is scheduled to occur in January 2007 for the
needs and in April 2007 for requirements)? This risk is raised in importance for this
development effort, because we do not plan on “deferring” any significant areas of the standard
to an ensuing development cycle.
Risk area #3- Scheduled review times are short (or over holiday periods) so we don’t get
adequate reviews
In order to maintain the overall schedule of developing the standard, the amount of time allotted
for review prior to each technical review has been set at 10 working days in most cases. In one
case (review of the second draft of the concept of operations) this review period falls during the
end of year holiday season. The risk that is identified is that key people will not give the
material an adequate review, resulting in a lack of consensus.
Risk area #4 – The user needs and requirements workshop provides an overwhelming collection
of new material which exceeds the available project budget.
It is possible that input obtained during the workshop and from comments received from
deployers will identify additional user needs and requirements that far exceed the concept of
modifications and updates to the TMDD V2 that was included in the project budget and work
plan. Note that this does not include new material we expect to receive for the CLARUS and
ADUS content. Example: There are many agencies who want to see significantly more detailed
information exchanged about a device to support microscopic device monitoring and
management. So for example, the “need” may be identified to add messages to deal with traffic
controller timing plan details, intersection configuration details, message logs, sign fonts, etc.
This need in turn creates the requirement to add C2C messages for significantly more of the
NTCIP data elements than expected. Such significant additions could take weeks of additional
effort when you include the ConOps, requirements, SRS, and finally the dialogs and messages –
plus all of the committee discussions and review comments.
Risk area #5 – the results of the workshop and the preliminary development of the ConOps and
requirements show that there are many changes requested that could “break” backward
compatibility.
There are many existing deployments which are using or attempting to use the messages shown
in V2, and this project has the goal of maintaining backward compatibility or dealing with the
consequences. Addressing the inputs from some deployers (e.g. problems they have encountered)
7
might cause changes that would impact backwards compatibility for other deployers. The risk is
that the development may not be able to satisfy both cases (changes requested by one developer
vs. backward compatibility for another).
Risk area #6 - Creating standards outputs that are ISO 14817 conformant.
TMDD is the first ITS standard to commit to create outputs that are ISO 14817 conformant and it
may be harder to do than expected. The risk is that some aspects of ISO 14817 might be difficult
to create or that they may be difficult to use with the tool set planned for the development.
3.5.1.2 Risk Analysis and Prioritization

For the risk areas identified, these risks need to be categorized in terms of the type of risk,
magnitude of the risk, and likelihood of the risk occurring.
Risks that may affect the project will fall into three general categories:
 Technical (risks affecting the completeness or correctness of the resulting standard)
 Schedule (risks that cause schedule slippage)
 Cost (risks that cause cost to exceed budget)
The magnitude of risk can be characterized as:

 Large (having significant impact in any category)
o Technical- resulting in errors that do not allow deployments to use parts of the
standard as developed
o Schedule- resulting in schedule slippage of over 2 months
o Cost- resulting in cost overrun of more than 5%
 Medium (having major impact in any category)
o Technical- resulting in errors that require additional committee work to resolve
o Schedule- resulting in schedule slippage of 1-2 months
o Cost- resulting in cost overruns of less than 5%
 Small (having minor impact in any category)
o Technical- resulting in minor errors in the standard that can be corrected through
the normal standards maintenance process
o Schedule- resulting in schedule slippage of 1-3 weeks
o Cost- resulting in cost expenditures that don’t match budget plan, but do not
exceed the overall budget.
The likelihood of risk occurring can be characterized as:

 High (greater than 30%)
 Medium (less than 30 %)
 Low (less than 10 %)
8
Given these three dimensions, the risk areas for the project can be analyzed and prioritized. This
is summarized in Table 1.
Table 2: Summary of Risk Analysis and Prioritization
Risk Area Category Magnitude Likelihood Priority
Risk area #1: Don’t get correct or Technical Medium Medium 1
complete inputs at the Needs
Assessment Workshop
Risk area #2- New needs (or Technical, Medium Low 2
requirements) come in late in the Schedule,
process and Cost
Risk area #3- Scheduled review times Technical Small Low 3
are short (or over holiday periods) so
we don’t get adequate reviews
Risk area #4 – Large amount of new Technical, Medium Medium 1
requirements exceed project Schedule,
expectations. and cost
Risk area #5 – Backward compatibility Technical, Medium Low 2
problems are encountered with Schedule,
deployments. and cost
Risk area #6 – Creating standards Technical, Low Medium 2
outputs that are ISO 14817 conformant
Risk area #1: Don’t get correct or complete inputs at the Needs Assessment Workshop represents
a primarily technical risk that new needs or requirements will not be captured early enough in the
development process. The magnitude of the impact is judged to be medium since missed needs
or requirements could result in errors in the standard that would require committee rework at a
later date. The likelihood is judged to be medium since some key participants in the process
(deployers) will not be funded to attend the needs assessment workshop, and may not choose to
attend. From a prioritization standpoint this is judged to be the highest priority risk and one that
will be closely monitored.
Risk area #2- New needs (or requirements) come in late in the process represents a primarily a
technical risk, but does have cost and schedule components if the new requirements require
additional iteration through of parts of the process. The magnitude of this risk is also judged to
be medium, due to potential to impact schedule or cost. The likelihood is considered low,
because of some of the risk mitigation features built into the project plan (see discussion below).
From a prioritization standpoint this is judged to be the second highest risk and one that will be
closely monitored. Update at mid project- this risk did occur an have an impact on both
schedule and budget. Our original plan called for development of user needs (in the Concept of
Operations), then requirements, and then design. The expectation was that some minor edits to
needs would occur after the “final Concept of Operations deliverable” and that some minor edits
would occur after the delivery of the final Functional Requirements deliverable; however the
magnitude of the changes to these aspects of the program, months after we have completed the
final Task 2 documents has been considerable. We continue to get requests to review and rewrite
portions of the user needs. As we continue the design we are also seeing significant rewrites of
9
the functional requirements sections. It is clear that sufficient review of these outputs was not
accomplished as we delivered the initial outputs and we still have to expend considerable time
and hours working these sections of the standard. As a lesson learned for future, it seems likely
that all standards efforts will have the same issue- the committee just isn’t used to viewing the
standard from a needs standpoint and project plans should expect considerable rewrite later in the
process.
adequate reviews is primarily a technical risk. The magnitude of the risk is judged to be small,
since there are multiple reviews and the impact from any one review is diluted. The likelihood is
small as well, given the planned approach to technical reviews discussed below. From a
prioritization standpoint this is judged to be lowest of the identified risks, but it will be
monitored during the development. Update at mid project- the issue of adequate review has
occurred and had an impact on both schedule and cost. The amount and scope of comments we
continue to get on the Concept of Operations and functional requirements indicate that the initial
reviews were not adequate. The observation (in hindsight) is that the TMDD committee
members, who are drawn from the deployment community, don’t resonate to needs/ requirements
like they do to design, and we find over and over again that the real needs/ requirements are not
defined until the details of design are debated.
Risk Area 4 - Large amount of new requirements exceeds project expectations. This is primarily
a technical risk and has been a long standing issue of discussion within the TMDD program in
the past. The distinction between the high level device abstraction and how to handle off-hours
operation has been an issue which was previously dealt with. However, since some of the early
deployers have used C2C communications for detailed device management, this is likely to
become an issue again; hence, the likelihood is medium that this will occur depending on the
participants at the workshop. If it does occur, it is likely to affect the schedule and budget as the
additional dialogs and message sets are developed to support these requirements. Update at mid
project- this risk has occurred and has had an impact on schedule and budget. The scope of the
requirements document has grown considerably since the beginning of the program, with over
1100 requirements now defined. In addition, the team has undergone a complete rewrite of these
requirements to achieve a consistent style and to fully define the “optional” aspects of the
requirements. One of the risk mitigations we put in place was to use an automated requirement
tracking tool, Requisite Pro, to manage the requirements and their traceability. Unfortunately the
team had a difficult time getting the committee to agree to the final form of the requirements and
the wholesale rewrite of the requirements forced the development team to delay putting
information into the traceability tool (which requires reentry of the requirements each time they
are “reorganized” or rewritten in any significant way). The tool will ultimately provide a very
good measure of assurance that the trace is complete and correct, but the effort to populate the
tool and make the initial mapping has proven to be far greater than anticipated. Finally, the
extent of new requirements has far exceeded our original project specifications. This is partly
due to the ambiguity in the scope of the project relating to fixing “deficiencies” in the standard.
The committee has defined a number of areas that represent new capabilities for TMDD (e.g.
passing routes, second-by-second traffic signal control information, and turning movements). As
10
we have proceeded to design, the effort required to address these new areas (requirements and
design) has grown considerably.
Risk area #5 – the results of the workshop and the preliminary development of the ConOps and
requirements show that there are many changes requested that could “break” backward
compatibility. There are many existing deployments which are using or attempting to use the
messages shown in V2, and we need to identify a mechanism for maintaining backward
compatibility or dealing with the consequences. The likelihood that this will occur is medium.
The impact should be low as one mechanism available to solve the issues is to keep the old
messages and simply add new messages to meet the updated needs and approaches.
Risk area #6 - Creating standards outputs that are ISO 14817 conformant. This is primarily a
technical risk, although it could impact schedule or cost if not handled properly. Given a good
mitigation plan the impact of this risk should be low. Based upon the initial review of ISO
14817 requirements (see section 3.5.3.1) the likelihood of occurrence is judged to be medium.
3.5.1.3 Risk Mitigation

For each risk identified a mitigation strategy should be developed. For the three risk areas
identified here are the risk mitigation strategies:
Risk area #1: Don’t get correct or complete inputs at the Needs Assessment Workshop
The committee chair and the contractor team will coordinate with key deployment or standards
representatives to clearly identify the information needed and will follow-up prior to the
workshop to ensure they understand and are able to provide the information. If incomplete
information is obtained the committee chair or contractor team will contact and engage the
affected stakeholders directly following the workshop.
Risk area #2- New needs (or requirements) come in late in the process
The mitigation strategy for risk area 1 will reduce the likelihood of this risk area occurring (by
uncovering the complete set of requirements and needs). The schedule does recognize that some
changes in needs/ requirements will occur and has built in effort (from a cost standpoint) to deal
with these. Updated risk mitigation at mid project- Automation is now in place to support faster
creation and update of sections of the standards that are under discussion, allowing faster
turnaround on new outputs. Two additional outputs/ reviews have been planned to resolve issues
arising from the design.
adequate reviews
The three primary mitigations to this risk area are
1. Invite the full set of affected stakeholders to each technical review. So if one reviewer
does not get a full review, there will be others who do.
2. Hold many of the technical reviews via webcast or similar so physical presence isn’t
required. This will increase attendance at the reviews, particularly by those parties who
aren’t directly funded to attend meetings.
11
3. Hold real technical walkthroughs that cover the changes page by page- allowing detailed
comments to be made and recorded on the spot.
Updated mitigation at mid project- Subgroups have been identified for 7 key areas of the
standard. These small groups of experts in the particular area will perform a detailed review of
the sections of the standard relating to their expertise and will engage in several telecons with the
development team to identify and resolve issues relating to the subgroups area of expertise. As
part of this effort the subgroups will closely review the requirements as well as the design.
Risk area #4 – Overwhelming set of new requirements.

While we will attempt to restrict the discussions at the workshop to “updates” or “changes” to
the V2, it is likely that some of the key players will push forward an agenda for more detail and
significantly more messages dealing with device level management. One possible solution is to
invent a more generic approach for such device level management by encapsulating SNMP
OID’s and values to support SET and GET between systems; other alternatives include limiting
the feature set of functionality supported in the C2C environment or reverting to the concept of
remote log-in where detailed device management is necessary. Updated mitigation at mid
project- the additional mitigation efforts mentioned for Risk Area 2 also apply to Risk Area 4.
Risk area #5 – Problems with backward compatibility.
One of the first risk mitigation actions is to develop a definition of backwards compatibility as it
relates to TMDD. Following creation of this definition, the contractor will then define how this
definition will be applied to V2 messages and data. One approach to be considered is to preserve
existing message sets with a notation that newer versions should be used for new designs. In
addition, we can work with the early deployers to work out changes that will have a minimal
impact. As we go through the process of updating to V3, the contractor will keep this in mind
and bring such issues to the TMDD MS/ETMCC Steering Committee early in the development
to avoid costly re-do/re-work later.
Risk area #6 - Creating standards outputs that are ISO 14817 conformant.
The primary mitigation for this risk is to develop an example set of ISO 14817 conformant
outputs early in Phase 2 of the effort, so that any issues relating to this risk can be identified early
and resolved. Subtask 2.3.1 has been created to create these example outputs. Examples of
interface dialog, message, data frame, and data element will be created.
3.5.1.4 Risk Monitoring

Risk monitoring defines when and how the risks will be monitored. The plan for monitoring is
to review the risk areas at monthly project telecons. In addition this plan will be updated at the
transition from Task 2 to Task 3 of the project in order to review the basic risk areas and add or
delete areas as appropriate. We will also be tracking the parties providing input to ensure that we
have obtained input from all known interested parties.
3.5.2 Configuration Management Plan

Configuration management is defined as: “A management process for establishing and
maintaining consistency of a product’s performance, functional, and physical attributes with its
requirements, design and operational information throughout its life” (ANSI/EIA 649-1998).
12
This plan for configuration management of the TMDD MS/ETMCC V3 development effort
identifies an initial set of outputs that will form the baseline and discusses the planned process
for managing the configuration of the baseline outputs.
3.5.2.1 Baseline Outputs

The following products of the development effort form the initial definition of the baseline that
will come under configuration management:
 TMDD MS/ETMCC V3 standard: This represents the various document outputs that will
occur during the development process.
 Traceability files. This is the file that defines the traceability of needs to requirements. The
tool Rational RequisitePro has been chosen for the traceability effort, so this will be a file stored
in a format used by the tool (Microsoft Access format). An Microsoft Excel version of the Needs
to Requirement Traceability Matrix (NRTM) and Requirements Traceability Matrix (RTM) will
be delivered.
 ASN.1 module files representing the ISO 14817 meta data of the TMDD.
 ASN.1 module file representing the TMDD data concepts.
 TMDD Web Services Description Language (WSDL) file representing the TMDD dialogs.
 • TMDD XML Schema file representing the TMDD messages, data frames, and data
elements.TMDD MS/ETMCC V3 Data concepts database. This will be a Microsoft Access
database that contains the dialogs, messages, data frames, and data elements that define V3.
 Data Concepts diagram file. Microsoft Visio with the PHRUBY UML 2.0 UML Stencil will
be used to create UML Sequence Diagrams, which will capture the information related to
interface dialogues.
 Traceability file. This is the file that defines the traceability of needs to requirements to data
concepts. The tool Rational RequisitePro has been chosen for the traceability effort, so this will
be a file stored in a format used by the tool (probably a Microsoft Access file).
 Comment Database. This will be a Microsoft access database that contains comments
received against this (and earlier) version of the standard.
 Configuration Status Report. This document will identify the baseline versions of each
output as well as document the tool versions (e.g. the version of Microsoft Access) used to create
or contain each of the outputs. The Configuration Status Report will show the title, document
number, creator, and version (where applicable) for all project documents.
 Project Management Plan and System Engineering Management Plan
 TMDD MS/ETMCC Steering Committee meeting documentation (e.g. minutes, agendas, and
presentations).
 MiniEdit executable and instructions. If this tool is used to create outputs for the standard,
then the executable version of the tool will be part of the baseline
All of the documentation created on the project will employ a document numbering scheme that
contains document name, version (if applicable), and date of document creation.
13
3.5.2.2 Change Control Procedures and Baseline Management

Baseline Creation of Comments Database and Comments Traceability
The initial baseline of the comments database will be created from the list of current outstanding
(unresolved and new comments) on TMDD v2.1.
A comments database will be maintained to track comments and resolution status, as well as to
define the resolution itself and impact on the TMDD V3 (specifically, tracing to any ConOps,
Requirements, and Data Concepts requiring a change).
Key fields from the Comments Tracking and Resolution table are shown below.
 CommentId – Unique ID assigned to the comment.

 CommenterAndOrganizationContact – Person providing comment, organization, and e-
mail address, which will provide a way to contact commenter in case clarification is
needed.
 DateOfComment – Date Comment received by SDO.
 StandardVersionDate – Version and date of the standard to which comment applies.
 PageParagraph – Page and paragraph comment applies to.
 Comment – The comment.
 StandardsItemType – Type of standards item impacted by comment: ConOps,
Requirement, DataConcept.
 StandardsItemId(s) – Id of item impacted.
 Developer – Name of developer assigned to dispose of the comment.
 ProposedResolution – Description of change to the standard to address the comment.
 ApprovalStatus – Description of status of comment resolution.
 ApprovalDate – Date upon which approval to make change took place. (The TMDD
MS/ETMCC Steering Committee is the group that grants approval.)
Managing Updates to the TMDD V3

The following describes the process for addressing comments and managing updates to the
TMDD V3:
 ITE receives comment(s) and assigns a comment ID. Commenters are expected to
provide comments using a standardized comment form.
 Comment is forwarded to developers.
 Comments Database is updated to log comment.
 Developer proposes resolution and identifies what standards items that will be changed.
 Comments and Resolution Authority (Steering Committee) provides approval of
resolution. (Note that some comments will be presented to the TMDD MS/ETMCC
Steering Committee for approval at meetings, while others will be circulated
electronically and discussed and approved via teleconference)
 TMDD V3 is updated.
14
 Once all comments have been disposed the TMDD is ready for general public release.
When all comments are resolved the comments database will be added to the version of the
TMDD for which the standard applies (see next section).
Comments will be a rolling database to track all comments throughout the life of the TMDD V3.
3.5.2.3 CM Plan for Systems and Related Documentation

This subsection includes the configuration management plan for the system and related
documentation, and programmatic documents such as meeting minutes and schedules. The
baseline outputs that will be put under configuration management are defined in Section 3.5.2.1.
The system documents (minus comments database) will be packaged into a zip formatted file, for
which the date remains stable. The comments database will be added as a separate entry.
The processes for configuration management are described below:

 User access management. Three levels of users will be defined: developers,
reviewers, and the public. Individual developers and reviewers will be assigned user
names and passwords to control access. Once the standard is ready for access by the
public, the standard will be accessible via a link on the ITE web site.
 Check in / check out. Developers will have full edit (read-write) capability and
check-in/check-out (implemented as ftp upload/download) capabilities for the
standard. Reviewers will have read-only access and check-out (implemented as ftp
download) capabilities . Check-in/check-out is not applicable to the general public.
Reviewers are expected to provide comments using a standardized comment form.
(The form fields as shown in the section on Change Control Procedures and Baseline
Management.)
 Standard date and version numbering. The official date and version of the standard
will be assigned by the ITE and forwarded to the developers.
 Electronic document package management. Each version of the TMDD will be
tracked in a specific directory on the project web site. A zip formatted package of
electronic documents and sources will be provided as described in the previous
section
3.5.3 Verification and Validation Plan:

Verification and validation of whether the information content of the TMDD is complete and
correct will rely on two reviews of the pertinent information:
1. The contractor team will perform a check for completeness and correctness of the needs
and requirements. This check will be presented to stakeholders as part of the technical
reviews.
2. Stakeholders will review and comment on the check of needs and requirements
performed by the contractor to ensure that all user needs are defined and that the
requirements stated satisfy a particular user need.
The Needs to Requirements Traceability Matrix (NRTM) (discussed in section 3.5.5) will form
the basis for this check and its review by the stakeholders.
15
The Requirements-Message Set Data Concepts traceability table will verify that requirements
trace to a “data concept” of the TMDD: data element, data frame, message, or interface dialog.
This table, called the Requirements Traceability Matrix (RTM) will be created from the Rational
RequisitePro traceability tool. The table will map from requirements to dialogs and messages.
The typical dialog is in the form of a request mesage/ response message. Due to the nature of the
requirements some of the requirements will map to the request message of the dialog and some
will map to the response message of the dialog. The table will then be extended (or possibly
done as a second table) to show the mapping of requirements to data frames/ elements. This
latter mapping will address the mapping of subrequirements to the portions of a message
satisfying each requirement. The verification and validation of this mapping will follow a
similar two step process as given above:
1. The contractor team will create the RTM and perform the initial check that all
requirements are satisfied by design elements.
2. Stakeholders will review and comment on the mapping of requirements to design
elements to ensure that all the requirements are completely covered by the design.
In this way, the RTM will be used to verify and validate that the message set solution satisfies
one or more information exchange requirements.
3.5.3.1 Approach to ISO 14817 Standard Compliance

This subsection describes the approach for verifying compliance with ISO 14817 standard. The
following is a suggested approach which will need to be reviewed and approved by the TMDD
MS/ETMCC Steering Committee.
Section C.3 of the 14817 standard states that a data dictionary need only contain definitional
information related to the following data concepts: data elements, data frames, messages, and
interface dialogues. Tables A.1 through A.4 in the appendix of this document (organized by data
concept type) shows the list of 14817 meta attributes that apply to a data concept and whether
they are mandatory or optional. Two additional columns have been added: the first indicates
whether the MiniEdit tool (version 2.0.410) supports the attribute, and the second column shows
whether the meta attribute will be maintained for TMDD V3.
Issues related to compliance with ISO 14817

The development plan calls for use of the tool MiniEdit to create output formats of the messages
and data frames/ elements. This approach was successfully used in TMDD V2 development.
Consideration of how the tool will support the conversion to ISO 14817 formats is an issue that
will need to be addressed. In order to make an initial assessment of this issue, the current
capabilities of the MiniEdit tool (version 2.0.410) were assessed to determine how the 14817 will
be used for the TMDD MS/ETMCC. More specifically, the review included the following:
- what meta data fields will be used (addressed in the previous section);
- how the naming rules will be employed;
- what changes will be required to the MiniEdit tool for the printing of future annexes for
the TMDD MS/ETMCC standards.
This is an initial analysis for the purpose of defining a basic approach to 14817 compliance and
will need to be further reviewed with the TMDD MS/ETMCC Steering Committee, the
developer of MiniEdit, and possibly other affected standards organizations.
16
Table 3. Summary of MiniEdit Support for 14817 Compliance Review

Compliance Section of ISO 14817 Standard Comment
Item
Meta attributes Annex B includes definition of MiniEdit supports most mandatory attributes of ISO
Capture terms 14817. Exceptions include: ASN.1 OID, and attributes
Annex C.3 and Table C.3 includes related to ITS Architecture reference. Following creation
list of mandatory, optional, of the example outputs, the contractor will determine the
assigned, and conditional changes required to MiniEdit to support this and will
attributes on a data concept basis create a final tool plan to support the effort. The ASN.1
Name will be used to relate the new data base to the
MiniEdit DB.
Naming Rules Section 9.2 includes definition of Changing the Descriptive Name does not impact other
Descriptive Name naming rules. standards that reference TMDD data concepts.
Section D.1.4 contains list of
value-domain-term names.
Output Annex F Following creation of the example outputs, the contractor
documentation will determine the changes required to MiniEdit to support
output documentation creation andand will create a final
tool plan to support the output documentation.
There are two additional issues related to ISO 14817 compliance that will have to be addressed
in the development effort. ISO 14817 does not state how to relax the mandatory attribute in the
case of no ISO authority able to assign on ASN Object Identifier (OID) or acting as a data
registry. So to fully comply, ITE will need to obtain an ISO node to grant ASN OIDs.
ISO 14817 also does not state how to relax the mandatory attribute in the case of no established
data registry. This relates to the ISO 14817 requirement that import and export of data elements
(i.e., reference to a data element) shall be to a data registry. At present there is no data registry to
which this could apply.
3.5.4 Technical Reviews

Technical reviews provide a structured and organized approach to reviewing project products to
determine if they are complete, correct, and accurate. Technical reviews are used to identify
defects (in needs, requirements or design) and identify alternative solutions. They are also used
to clarify outputs (needs, requirements, or data concepts) and create a common understanding
among the reviewers of the material. These reviews represent the “control gates” that must be
passed before the project can proceed to the next step in the development process. provides a
summary of the planned technical reviews for the project.
Table 4: Technical reviews
Technical Review Date Type Length (days)
Task 2.1.3 Technical Walkthrough of Draft 11/30/06 Web 1
Concept of Operations
Task 2.1.5 Technical Walkthrough of Second 1/4/07 Web 1
Draft Concept of Operations
Task 2.2.2 Technical Walkthrough of Draft 2/22/07 Web 1
Standards Requirement Specification
Task 2.2.4 Technical Walkthrough of Second 3/22/07 Web 1
Draft Standards Requirements Specification
Task 2.3.2 Technical Walkthrough of Draft 6/12/07 Face-to 2
17
Technical Review Date Type Length (days)

Design Content faceWeb
Task 2.3.4 Technical Walkthrough of Second 7/22/07 WebFace- 21
Draft Design Content to-Face
Task 2.3.7 Technical Review of Third Draft 9/11-14 Web 4
Task 2.3.7 Technical Review of Third Draft 10/30-31 Web 2
Task 3.4 Technical Walkthrough of Comments 11/12/07 Web 1
Addressed on User Comment Draft of TMDD
V3 Standard
The following provides a discussion of the process that is anticipated for conducting the
technical walkthroughs.
Since TMDD MS/ETMCC V3 is an update to TMDD V2.1, at each step along the development
path it is possible to define the changes that have occurred from the previous version. The plan
for each walkthrough is to go through the portion of the standard being reviewed (e.g. concept of
operations) page by page, discussing the changes and soliciting comments on the proposed
changes. Each technical review will have a draft review output made available two weeks prior
to the meeting for review by the TMDD MS/ETMCC Steering Committee and other interested
parties. Comments received prior to the walkthroughs and comments received at the
walkthroughs will be entered into the comment database. As a part of each walkthrough the
changes to the comment database (new comments and resolutions to old comments) will be
reviewed with the walkthrough attendees.
3.5.5 Requirements Traceability

One of the key control and validation activities of the development will be tracing requirements.
This tracing will occur in two directions- backwards to the user needs defined in the concept of
operations and forward to the specification of dialogs, messages, data frames, and data elements.
To perform this traceability we will use the Rational RequisitePro software tool to automate the
process.
Two types of traceability will be managed throughout the development process: 1) Concept of
Operations to Requirements traceability, called a Needs to Requirements traceability, and 2)
Requirements to Design traceability, called a Requirements Traceability.
Each of the following will be given a unique ID to support traceability:

- ConOps User Need
- Requirement
- Interface Dialogue (ASN1 Name for readability)
- Message (ASN1 Name for readability)
- Data Frame (ASN1 Name for readability)
- Data Element (ASN1 Name for readability)
Baseline Creation of Traceability Matrices

The TMDD v2.1 User Needs and Requirements will be parsed and entered into RequisitePro to
create the TMDD V3 baseline content. A Needs to Requirements Traceability Matrix (NRTM)
18
will be developed based on the information put into the tool. Key fields from the NRTM are
shown below.
Table 5. NRTM Fields

ConOpsId ConOpsDocSection UserNeed Func Req Func Req Project Additional Project
ID Use Req/ Comments
ID defined Corresponding User need ID defined Text of
in tool section in ConOps in tool Functional
document Req
The Project Use section will be a topic of discussion with the Steering Committee. Should it
continue as in the current version (where it defines a universal vs project specific requirement) or
should it be replaced by an actual conformance indication – e.g. mandatory vs optional). The
same goes for the Additional Project Requirements/ Comments column. This might continue as
in V2, or be modified to contain comments, possibly relating to conformance.
Key fields for the RTM are shown below:
Table 6 Requirements Table Fields

ReqId RequirementsDocSection Requirement DataConceptType DataConceptId(s)
Requirements Corresponding section in Requirement Short-hand 14817 Comma-separated list of
Identifier Requirements document Data Concept Type. data concept ASN names
Eg., DE for Data that satisfy this requirement
Element.
Throughout the project these tables will be updated at each step in the process.
4 Applicable Documents
The following documents are referenced in this system engineering management plan:
ITE/ AASHTO Standards for Traffic Management Center to Center Communications, Version
2.1, June 1, 2005
ISO/FDIS 14817:2002(E), Transport information and control systems — Requirements for an

ITS/TICS central data registry and ITS/TICS data dictionaries, 2002-07-01
INCOSE-TP-2003-016-02, Version 2a, SYSTEMS ENGINEERING HANDBOOK, 1 June 2004
ANSI/EIA 649-1998, National Consensus Standard for Configuration Management
ANSI/AIAA-G-043-1992, Guide for the Preparation of Operations Concept Documents
19
Appendix: 14817 Compliance Related Tables – Preliminary

This appendix identifies the meta data identified in ISO 14817 that will be added to and included
in the TMDD MS/ETMCC V3. This table contains the preliminary approach to 14817
conformance and is subject to review and approval by the TMDD steering committee and should
be reviewed by the other Standards Development efforts (IEEE 1512, SAE ATIS, NTCIP) to
ensure consistency amongst the working group outputs. As is shown in the following tables the
TMDD V3 will address all the mandatory attributes for each data concept. As an aid to creation
of an end-to-end example for each data concept the support of the tool MiniEdit for the metadata
is indicated.
The following are the definitions of the abbreviations used in the Requirements Type column of
the tables.
"M" = mandatory. Mandatory meta attributes are required for the referenced data concept,
without exception.
"O" = optional. Optional meta attributes may be implemented if desired by the functional-area
data dictionary.
"C" = contingent. Contingent meta attributes are those that depend upon the implementation of
an optional meta-attribute. They are required when the optional meta-attribute upon which they
depend is implemented.
"I" = indicative. Indicative meta attributes depend upon an "if" condition that is independent of
any other meta-attribute. If the "if" condition is applicable, then the "I" coded meta-attribute is
mandatory; otherwise, it is not applicable.
Table A.1: 14817 Attributes for TMDD V3 Data Elements
14817 Meta 14817 Meta Attribute Requirement TMDD

Attribute Id Name Type MiniEdit Field V3
B.2.1 Data concept identifier O DATACONCEPT-IDENTIFIER
B.2.2 Data concept version O DATACONCEPT-VERSION
B.2.3 Descriptive name M DESCRIPTIVE-NAME X
Synonymous descriptive
B.2.4 names O Not Supported
B.2.5 Symbolic names O SYMBOLIC-NAME
B.2.6 ASN.1 name M ASN1-NAME X
B.2.8 ASN.1 object identifier M Not Supported X
B.2.9 Uniform resource locator I Not Supported
B.3.1 Definition M DEFINITION X
B.3.10 Context O Not Supported
B.3.11 Standard M SOURCE-STD X
B.3.16 Data quality O Not Supported
B.3.2 Descriptive name context M DESCRIPTIVE-NAME-CONTEXT X
B.3.3 Symbolic name usage C SYMBOLIC-NAME-USAGE
B.3.4 Source O SOURCE
B.3.5 Architecture reference O Not Supported
B.3.6 Architecture name C Not Supported
B.3.7 Architecture version C Not Supported
B.3.8 Data concept type M DATACONCEPT-TYPE X
B.3.9 Remarks O REMARKS X
20

B.4.13 Referenced data frames O Not Supported
B.4.14 Referenced data elements O Not Supported
B.4.15 Referenced object classes O Not Supported
B.4.2 Precursor O Not Supported
B.4.3 Successor O Not Supported
B.4.4 Synonym O Not Supported
B.5.1 Data type M DATA-TYPE X
B.5.1 Data type M MESSAGE-BODY X
B.5.2 Format M REPRESENTATION-LAYOUT X
B.5.3 Unit of measure M UNITS X
B.5.4 Valid value rule M VALID-VALUE-RULE X
B.6.1 Registration status O REGISTRATION-STATUS
B.6.10 Submitter phone number O SUBMITTER-PHONE-NUMBER
B.6.11 User O USER
B.6.12 View O VIEW
B.6.13 Related groups I Not Supported
B.6.14 Security class O SECURITY-CLASS
B.6.2 Date registered O Not Supported
B.6.3 Last change date O LAST-CHANGE-DATE
B.6.4 Last change user O LAST-CHANGE-USER
Registrar organization REGISTRAR-ORGANIZATION-
B.6.5 name O NAME
B.6.6 Registrar phone number O REGISTRAR-PHONE-NUMBER
Steward organization
B.6.7 name O STEWARD-ORGANIZATION-NAME
B.6.8 Steward phone number O STEWARD-PHONE-NUMBER
Submitter organization SUBMITTER-ORGANIZATION-
B.6.9 name O NAME
Table A.2: 14817 Attributes for TMDD V3 Data Frames

B.3.5 Architecture reference O Not Supported
B.3.6 Architecture name C Not Supported
B.3.7 Architecture version C Not Supported
21

B.3.9 Remarks O REMARKS X
B.4.14 Referenced data elements M RELATIONSHIP-TYPE X
B.4.14 Referenced data elements M RELATED-DATA-CONCEPT X
B.6.11 User O USER
B.6.12 View O VIEW
B.6.5 name O NAME
B.6.9 name O NAME
Table A.3: 14817 Attributes for TMDD V3 Messages

B.3.12 Metadata source M Not Supported X
B.3.13 Priority M PRIORITY X
B.3.14 Frequency/message mode M Not Supported X
B.3.15 Delivery verification O Not Supported
B.3.5 Architecture reference M Not Supported X
B.3.6 Architecture name M Not Supported X
B.3.7 Architecture version M Not Supported X
B.3.9 Remarks O REMARKS
B.4.13 Referenced data frames M RELATED-DATA-CONCEPT X
22

B.4.13 Referenced data frames M RELATIONSHIP-TYPE X
B.4.14 Referenced data elements M Not Supported X
B.6.11 User O USER
B.6.12 View O VIEW
B.6.5 name O NAME
B.6.9 name O NAME
Table A.4: 14817 Attributes for TMDD V3 Interface Dialogues
Meta Requirement TMDD

Attribute Id Meta Attribute Name Type MiniEdit Field V3
B.3.11 Standard O SOURCE-STD
B.3.5 Architecture reference M Not Supported X
B.3.6 Architecture name M Not Supported X
B.3.7 Architecture version M Not Supported X
B.3.9 Remarks O REMARKS
B.4.12 Referenced messages M Not Supported X
B.4.14 Referenced data elements O Not Supported
B.4.15 Referenced object classes M Not Supported X
B.4.16 Referenced associations C Not Supported
23
Meta Requirement TMDD

Attribute Id Meta Attribute Name Type MiniEdit Field V3
B.5.1 Data type O MESSAGE-BODY
B.5.1 Data type O DATA-TYPE
B.6.11 User O USER
B.6.12 View O VIEW
B.6.5 name O NAME
B.6.9 name O NAME
24

Systems Engineering Management Plan

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Systems Engineering Management Plan

Hochgeladen von

Copyright:

Verfügbare Formate

System Engineering Management Plan

Traffic Management Data Dictionary and Message Sets

An Informational Level Standard

TMDD SEMP-Draftv5.doc 0.00.1 7/14/06 B. Eisenhart Initial Draft

TMDD SEMP-finalv1.doc 0.10 8/15/06 B. Eisenhart Final

TMDD SEMP-finalv1-1.doc 1.0 10/13/0 B. Eisenhart Final- incorporating

TMDD SEMP- v1-2.doc 1.2 9/7/07 B. Eisenhart Update at mid project

The objectives for TMDD MS/ETMCC V3 are:

3 Systems Engineering Process

Figure 1: Systems Engineering Process

3.2 Concept of Operations

3.3 System Requirements

Relation to NTCIP Application Level Standards

Table 1: Summary of TMDD Application Profile Specific Content

Application Profile Data Concept Comment

3.5 Systems Analysis and Control

3.5.1 Risk Management Plan

Risk management includes the following general steps:

3.5.1.1 Risk Identification

3.5.1.2 Risk Analysis and Prioritization

The magnitude of risk can be characterized as:

The likelihood of risk occurring can be characterized as:

3.5.1.3 Risk Mitigation

Risk area #4 – Overwhelming set of new requirements.

3.5.1.4 Risk Monitoring

3.5.2 Configuration Management Plan

3.5.2.1 Baseline Outputs

3.5.2.2 Change Control Procedures and Baseline Management

 CommentId – Unique ID assigned to the comment.

Managing Updates to the TMDD V3

3.5.2.3 CM Plan for Systems and Related Documentation

The processes for configuration management are described below:

3.5.3 Verification and Validation Plan:

3.5.3.1 Approach to ISO 14817 Standard Compliance

Issues related to compliance with ISO 14817

Table 3. Summary of MiniEdit Support for 14817 Compliance Review

3.5.4 Technical Reviews

Technical Review Date Type Length (days)

3.5.5 Requirements Traceability

Each of the following will be given a unique ID to support traceability:

Baseline Creation of Traceability Matrices

Table 5. NRTM Fields

Key fields for the RTM are shown below:

Table 6 Requirements Table Fields

ISO/FDIS 14817:2002(E), Transport information and control systems — Requirements for an

INCOSE-TP-2003-016-02, Version 2a, SYSTEMS ENGINEERING HANDBOOK, 1 June 2004

ANSI/EIA 649-1998, National Consensus Standard for Configuration Management

ANSI/AIAA-G-043-1992, Guide for the Preparation of Operations Concept Documents

Appendix: 14817 Compliance Related Tables – Preliminary

Table A.1: 14817 Attributes for TMDD V3 Data Elements

14817 Meta 14817 Meta Attribute Requirement TMDD

14817 Meta 14817 Meta Attribute Requirement TMDD

Table A.2: 14817 Attributes for TMDD V3 Data Frames

14817 Meta 14817 Meta Attribute Requirement TMDD

14817 Meta 14817 Meta Attribute Requirement TMDD

Table A.3: 14817 Attributes for TMDD V3 Messages

14817 Meta 14817 Meta Attribute Requirement TMDD

14817 Meta 14817 Meta Attribute Requirement TMDD

Table A.4: 14817 Attributes for TMDD V3 Interface Dialogues

Meta Requirement TMDD

Meta Requirement TMDD

Das könnte Ihnen auch gefallen