IEEE WG 12 Software Meeting
04
January 12 & 13, 2000
Draft Meeting Minutes
The fourth meeting of the working group was held on January 12 and 13, 2000 at the PB World Offices in Newark, NJ.
The agenda was accepted as distributed. Document: sw agenda 04
The meeting 03 minutes from September 23 & 24, 1999 were distributed and one correction was made. The minutes were approved by voice vote.
The scope and purpose document that was incorporated into the PAR was distributed. The PAR has been submitted to NESCOM with one comment received to date and answered. The commenter questioned if the standard would address safety concerns such as train separation. The standard addresses software documentation concerns of format and content. Software safety is addressed by IEEE P1483 Standard for Software Safety.
The working group was
informed that the scope and purpose as approved by the IEEE must appear in the
standard without revision. If a
revision is required, the scope and purpose must be resubmitted for approval.
Bill Petiit was not able to attend the meeting. The information contained in Bill’s email was paraphrased. A copy of the email test appears below:
“Paul
Unfortunately, I will not be able to attend this
meeting. As a report on
my task from last month
regarding RR participation, I sent the following
message to a variety of
railroads.
=======================
Sent: Monday, November
15, 1999 8:52 AM
To: Gerard Sniffen
(Norfolk Southern); William Peterson (BNSF); Tom Trovato
(Florida East Coast);
Howard Moody (AAR); Phil
Abaray (UP); Larry Light
(Amtrak); Mike Choat (CSX); Bill Goodman (FRA); Joe
Mattingly (BRS);
Rnash@cpr.ca (CP); Alvan
Tom (CN); Robert.nash@cpr.ca
Cc: Paul Jamieson;
Thomas McGean; Jim Kyle
Subject: Working Group
for Standardized Software Documentation
The Institute of
Electrical and Electonics Engineers (IEEE) has formed a
Working Group (WG12) to
address standardization of software documentation
for rail systems. The preliminary scope and purpose of this
working group
are listed below. (Note that this is not related to
safety-critical
software as is being
discussed in the RSAC task force and in IEEE 1483). It
is intended that various
documentation requirements would apply to various
procurement types (e.g.
whether or not the end user would maintain and/or
modify the
software). Paul Jamieson of Wabco Rail
Electronics is chairing
this Working Group.
Scope
======
This standard
establishes the minimum requirements for application software
documentation throughout
the software development life cycle for rail
equipment and systems
including associated test and maintenance equipment.
Purpose
=======
Many differing
requirements for application software documentation are
presently being
specified for software used in rail equipment and systems
and for related
applications. This has led to a lack of standardization in
the information provided
on equipment and systems incorporating software.
This standard, when used
by the authority having jurisdiction, and
system/subsystem
suppliers is intended to specify documents that improve the
understanding of
software functionality, facilitate software corrections and
upgrades, improve
on-time delivery, assist in the development of quality
software,and lower
software acquisition and maintenance costs.
At the last Working
Group meeting, the question arose regarding whether
freight railroads have
an interest in participating in developing the
standard and/or using
the standard once developed. IEEE
standards are
voluntary consensus
standards developed under strict guidelines of openness,
balance of interest, and
due process. Use of the standard is
voluntary, but
they do have high
visibility and support as a standard.
Present members of
the working group
include FRA, consultants, suppliers, transit agencies and
commuter railroads.
Please respond to this
e-mail with your answers to the following questions.
Please pass this on to
anyone within your organization (or outside) that you
feel may have an
interest in this process.
1. As an end user, do
you feel that this standard would benefit the freight
railroads and would you
likely use it once it is completed?
2. If the answer to 1 is
yes, are you willing to participate in the
development of the
standard? Participation can be done
either through
attending meetings, or
providing comments to Working Group drafts.
Participation can also
be done as a "friend" of the working group where you
will receive meeting
minutes and have the opportunity to provide comments.
For more information on
the sponsoring group for this standard and other
related working groups,
see
http://www.tsd.org/wg.htm
For more information on
this particular Working Group, see
http://www.tsd.org/wg12.htm
=======================================================
CSX was very supportive
and is sending a representative to the meeting (Gary
Kujala). CP was supportive and asked to be on the
mailing list (Jim
Jardine, John
Ritchie). Alvan Tom (CN) told me they
were interested, but I
have not had an official
response from him yet. No other
responses were
received. Howard Moody (AAR) is already on the mailing
list.
My recommendation is to
include those members who have already responded and
keep the following
members on the mailing list for informational responses.
This will allow those
freight RR's not desiring to participate to be kept
aware of activities and
determine whether or not they wish to use this
standard. Sufficient interest was given on the part of
the freight
railroads to show that
some of them feel it is a useful standard.
Responded
Gary Kujala, Gary_Kujala@csx.com
Jim Jardine, Jim_Jardine@cpr.ca
John Ritchie, John_Ritchie@cpr.ca
Already on List
Howard Moody
Add to List for
Informational Purposes
Gerard Sniffen, gerry_sniffen@nscorp.com
William Peterson, william.peterson@bnsf.com
Tom Trovato, ttrovato@feci.com
Phil Abaray, phil_m._abaray@notes.up.com
Larry Light, lightl@amtrak.com
Bill Goodman, William.Goodman@fra.dot.gov
Alvan Tom, Tom02@cn.ca
Bill”
The team assigned to report on the various aspects did not complete their respective assignments. As new participants joined the group, a review of the previous activities and direction was presented.
The table from meeting 02 and KRC presentation was distributed and reviewed. Each document was discussed.
The standard will address the entire software life cycle, such that when the standard is specified the final customer will be assured that all necessary software documentation is created and the software was developed according to accepted standards.
The minimum content of the standard follows
Required documentation
Reference existing standards as much as possible
The format and content of each document is described.
The sequence of document preparation is preferred.
Assignments made to review documents needs to consider these concerns:
Based on the document, determine the applicable standard, format and content required.
Is the document applicable to the industry in whole or in part?
Is the format and content acceptable?
Are their variations required? How are variations applied? Are variations constrained?
Are their deficiencies in the existing standards?
As the group spent significant time discussing the documents contained within the table. Time was not available to discuss the general standard framework as defined by the IEEE Style Guide.
How are these documents implemented? What are the requirements and templates?
2. Management & Planning Byron Frank
What are the requirements and templates for SQAP, SCMP, SVVP and SVVR?
3. ISQAP Presentation Martin Cloutier
Bombardier to provide a representation of the ISQAP and how is it implemented? Provide a structure and rationale for using the document?
4. Design – SFD, SRS & SDD Leroy Denney/William MacArthur
What documents [SFD, SRS and/or SDD] are required at this phase? What information needs to be contained within the SFD?
5. Testing Martin Cloutier/Shantilal Morar
What are the requirements and templates for STP, STPr and STR? Need to identify and resolve potential overlap that may exist between SVVP and STP.
6. User Documentation George Hacken
Determine if IEEE 1063 is applicable. How is version history, installation and maintenance [parameter modification, software modification, software reload/recovery, etc.}?
7. Traceability Matrix Martin Cloutier
Determine if IEEE 730 is applicable. Bombardier to provide a matrix sample. How is the traceability matrix used?
8. COTS Lori Karr
When utilizing commercial off-the-shelf software, these items need to be addressed:
What are the issues?
How to address in the standard as its own section and within the templates?
Are there types of COTS?
9. Standard Framework Paul Jamieson
A framework for the standard must be prepared. The framework needs to include the introduction material for review that captures the group discussions.
Assignments need to be completed by February 25, 2000.
The next meeting will be held on April 5 and 6, 2000 at NJ Transit Offices in Newark, NJ. An agenda will be distributed prior to the meeting.