1.2. References to
CyFlex Documents
2... Starting and Stopping dlogger
3.1. Specification File
Format
3.2. Specification File
Keywords
Logging Data
Using dlogger
A data logging program
called dlogger collects and logs test
results on the CyFlex test system for storage and use in the DARTS system. This
program is one of many software tools included with CyFlex.
This document describes
the dlogger program and how to use it.
Because dlogger interacts with various
parts of the CyFlex test system, several CyFlex terms and features are
mentioned throughout this document. For example: the terms events
and variables. These and other topics
are described in more detail in separate documents as referenced throughout the
text.
A list of topics
and where to find more information appears in a section of this document
called, CyFlex Documents.
Once dlogger collects and logs
the test results data, CyFlex transfers the data to the DARTS system using a
CyFlex external data manager service specific to that transfer. The DARTS
system provides data storage and analysis.
The dlogger program samples and logs the test results according to the user specified
setup. .
The data sampling
rate is defined in the specification (spec) file. However, external events and
even logical variables can be used to start and stop data sampling. As an
alternative to timer based logging, a named event can also be used to cause sampling.
The dlogger program can log up
to 384 channels of data, and at rates up to 500 samples per second.
Additionally, dlogger can log any real, integer, logical or string variable. It
can also log any member of a statistical, composition, property or emission
variable. For an explanation of variable types, refer to the CyberMetrix
document, CyFlex Variables, Units,
Computed Expressions.
Note: In order for a variable value to be logged,
the dlogger spec file must
include a DARTS (PAM) keyword as shown in the Specification File Keywords section of this
document.
CyFlex users
familiar with the software tools in CyFlex probably recognize the term events, which the test system uses to communicate
between processes. For example, the application Test Manager relies on various
events to automate and control testing. Events can tell Test
Manager
when to transition between modes and execute procedures. For more about events,
refer to the document called, CyFlex
Events.
Events can be used
to start and stop dlogger data sampling, and control the sampling
rate. The dlogger program is able to detect an event if specified by a
keyword(s) in the associated dlogger specification file. If the event does not
already exist, dlogger will create it. The event is “attached to”
by dlogger, which watches for
the event.. When the event occurs, dlogger executes an action
associated with the event per the spec file. (More about keywords appears below
in Specification File Keywords.)
Other CyFlex
programs, such as Test Manager, can create events. Additionally, the user
can create events to control dlogger using the commands shown in the Command Line Options
section of this document. For more about events and creating them, refer to the
CyFlex Events document.
The dlogger output files reside
in a directory on the test cell called, /data/dlog.
This is the default location. While data is being collected, the file is
written to a sub-directory, /data/dlog/logging.
When data collection is terminated, the file is automatically moved to another
sub-directory, /data/dlog/ready.
Next, a process (tranMove) transfers the file to a central node, into
/data/darts_dlogger/ready/$tc. An
external data manager then moves the file to the server where the data is
stored and available to the user for analysis using other tools that support
the DARTS system. When the process is complete, the system places an
acknowledgement file and a copy of the analyzed data file in the test cell sub-directory,
/data/dlog/complete.
The user can change
the test cell directory where the output files are written. If in the dlogger specification file
the user adds the @OUTPUT_PATH keyword followed by a new directory name, the output
file will be written to that location. However, the specified directory must
contain the same sub-directories for the output file that exist under the
directory, /data/dlog/. If those sub-directories
are not present, an error message occurs and dlogger does not start.
Output files follow
this naming convention:
spec_filenameYYYYMMDDHHmmSSsss.dlog
where:
YYYYMMDDHHmmSSsss is the Month/Day/Year/Hour/Minute/Second/Microsecond when the file was
created.
Example output
file:
$FormatRev
dlogger_id
$PAMHeaderData
(This line is normally blank and is a placeholder.)
$FixedMetaData
DESCRIPTION='dlogger
description'
TEST_ID='dlog_tpid'
TEST_TYPE='dlog_testtype'
MODE='TC103'
GROUP='dlog_enggroup'
PROGRAM='67781'
SCAN_INTERVAL=0.0200000000000000004163[sec]
SCAN_EVENT='none'
$Data
time,AC_AIR_OT_P.AV,A/F.AV,H_PK_CYL_P@1.AV,USER30@11.AV,INT_MNF_P_VARIANCE.RN,INT_MNF_P_VARIANCE.MX,INT_MNF_P_VARIANCE.MN,TEST_TM.AV
$Units
date-time,in_hg,NONE,psi,none,in_h2o,in_h2o,in_h2o,min
$Values
"20151221
152239.738",1.6,123.0,345.0,"no",7.1,7.1,7.1,0.000
"20151221
152239.742",1.6,123.0,345.0,"no",7.1,7.1,7.1,0.000
"20151221
152239.762",1.6,123.0,345.0,"no",7.1,7.1,7.1,0.000
"20151221
152239.782",1.6,123.0,345.0,"no",7.3,7.3,7.3,0.000
"20151221
152239.802",1.6,123.0,345.0,"no",7.5,7.5,7.5,0.000
"20151221
152239.822",1.6,123.0,345.0,"no",7.7,7.7,7.7,0.000
"20151221
152239.843",1.6,123.0,345.0,"no",7.9,7.9,7.9,0.000
"20151221
152239.862",1.6,123.0,345.0,"no",8.2,8.2,8.2,0.000
"20151221
152239.882",1.6,123.0,345.0,"no",8.6,8.6,8.6,0.000
"20151221
152239.902",1.6,123.0,345.0,"no",8.9,8.9,8.9,0.000
"20151221
152239.922",1.6,123.0,345.0,"no",9.3,9.3,9.3,0.000
"20151221
152239.962",1.6,123.0,345.0,"no",10.0,10.0,10.0,0.000
"20151221
152239.982",1.6,123.0,345.0,"no",10.4,10.4,10.4,0.000
"20151221
152240.002",1.6,123.0,345.0,"no",10.7,10.7,10.7,0.000
"20151221
152240.022",1.6,123.0,345.0,"no",11.1,11.1,11.1,0.000
"20151221
152240.042",1.6,123.0,345.0,"no",11.4,11.4,11.4,0.000
"20151221
152240.062",1.6,123.0,345.0,"no",11.8,11.8,11.8,0.000
"20151221
152240.082",1.6,123.0,345.0,"no",12.1,12.1,12.1,0.000
$
Start the dlogger program from the command line or using a script file. (For command
options, see the section below called, Command Line Options.)
When the dlogger program is started
from the command line, it reads a specification file based on the argument.
Example:
$ dlogger dlogger_spec.315
&
The default
filename of the specification file is /specs/dlogger_spec.###
where:
.### is the test cell
number.
Another method for
starting and controlling dlogger is through a test procedure, which is a
text file containing instructions for a test. A CyFlex program called Test
Manager
(gp_test) reads the test
procedure and directs the test accordingly. For more about test procedures and
managing tests, refer to the separate CyberMetrix document called, Test Manager.
More than one
instance of dlogger may be running simultaneously, with each copy performing
different functions based on its specification file. Each copy of the program must
have a unique name so that:
In the dlogger specification
file, the @REG_NAME keyword identifies the program instance.
Terminate the dlogger program from the
command line or using an event called, release_event
in the specification file. (For command line options, see the following section.)
A release_event
signals the end of a sampling interval, and terminates the dlogger program after writing
the data file.
To stop multiple
instances of dlogger using the release_event,
modify the respective specification file for each instance. The instances may
be released separately or simultaneously. If each instance is specified with a
different release_event, the
instances can be released separately. If all instances specify the same release_event, they are released at the
same time.
If a dlogger task has no stop_event
specified, the program closes the data file when the maximum number of scans is
reached. (This number is defined by the MAX_SCANS keyword in the spec file.) If
the @MAX_SCANS keyword is not defined in the specification file, dlogger, once started, continues
collecting data until a stop event is received.
An option entered
at the command line overrides the same option in the specification file.
Syntax:
dlogger
[dlogger_spec_file] [switch] [options] &
where:
dlogger_spec_file = the name of the DARTS logger
specification file
This is an argument and not required.
The default is: /specs/dlogger_spec.nnn
where:
nnn = the test cell number
Switch:
+H Writes a new file when enable_variable
becomes TRUE
Example:
dlogger /specs/dlog1
n=1000 interval=1[sec] &
The
command above starts processing of the file, /specs/dlog1. The first option
sets the number of samples to 1,000. The second option instructs that samples
be taken every second.
Options:
The
table below contains general descriptions of each option.
|
Command Line
Option |
Description |
|
start=strt_event |
The name of the
CyFlex input event that starts the data sampling. Example: start=start_dlogger |
|
stop=stop_event |
The name of the
CyFlex input event that stops the data sampling Example: stop=stop_dlogger |
|
rels=release_event |
The name of the
CyFlex input event that causes dlogger to exit Example: rels=rels_dlogger |
|
done=done_event_name |
The name of the
CyFlex output event that is sent when data sampling is done Example: done=dlogger_done |
|
interval=scan_interval [units] |
The time interval
between data samples Note: This must include units. Example: interval=1[sec] |
|
n=max_number_of_scans |
The maximum
number of data samples or scans to be collected Example: n=1000 |
|
sync=sync_event |
This is the name
of the CyFlex event that places an intermittent data line in the data file.
This can be used instead of the interval. Example: sync=dlogger_sync |
|
enable=enable_variable_name |
The name of the
CyFlex Logical variable that enables sampling Example: enable=enb_dlogger |
|
path=directoryPath |
This is the
directory that will contain the output file. This option can be a
STRING_VARIABLE which contains the directory path of the output file. The
default path is: /data/dlog Example: path=dlogger_path_var |
|
ftp_event=event_name |
The name of the
CyFlex event used to initiate closing the output file, moving it to /data/dlog/ready, and opening a new output
file in /data/dlog/logging (or other
specified output path). Example: ftp_event=dlogger_xfer |
The dlogger specification file
is made up of “keywords.” Each keyword begins with the “@” symbol, which
identifies for the dlogger program that the line is a keyword. The
text following the symbol on the next line describes an action or process for
the program to perform.
Example:
@START_EVENT
The keyword is
uppercase text without any blank spaces. The next line(s), called the keyword_value, specifies the action or
process.
Example:
@START_EVENT
start_logging
Certain keywords must
be specified in the specification file before dlogger can run. Those
keywords are identified in the table below as “Required.”
However, if a
function will not be used, the corresponding keyword does not have to be included
in the file.
The table below lists
all keywords available for dlogger specification files.
Several keywords are
required in the specification file, as indicated in the table below.
Certain keywords
support computed expressions. Those keywords and more about computed
expressions are described in the section of this document called, Computed Expressions.
|
Keyword |
Required |
Description |
|
@CLEAR_STATISTICS_EVENT |
No |
This event causes
the statistical buffers within dlogger to be reset to
0. Example: @CLEAR_STATISTICS_EVENT clear_stats This might be
used at the start of a test mode so that statistics only apply to data taken
in that mode. |
|
@DESCRIPTION |
Yes |
The user configurable description appears
at the top of the output file. Example: A simple string description is enclosed
in single quotes: @DESCRIPTION ‘This is a description of my test.’ A more complex description can be
constructed using a computed expression. @DESCRIPTION ’Torque sweep, model=’ + model +
‘, S/N= ‘ + serial If the CyFlex variables ‘model’ and
‘serial’ had values of “Sig 600” and “14026490” respectively, the following
would be written to the output file: Torque sweep, model=Sig 600, S/N= 1402690 An error occurs and the program exits if
the keyword is not in the spec file. |
|
@DLOGGER |
Yes |
This is to clarify that the spec file is
a dlogger spec file. It presently has no need for associated
data. Example: @DLOGGER dlogger_id |
|
@DONE_EVENT |
No |
The name of the event that is set when
the data collection is complete. This
is an output event and can be used to inform another process that the output
file is now available. Example: @DONE_EVENT logging_done When the event is received, the data file
is moved to the /ready directory. |
|
@ENABLE |
No |
The enable variable is a logical variable
that must be set to TRUE before logging can take place. Typically, this
variable is set in a gp_test procedure or manually by the user. It may be
used to turn logging on and off at different modes of a test. Example: @ENABLE logging_ok |
|
@FIFO_LOG_BUFFER |
No |
Activates First-in First-out (FIFO)
logging. This keyword allows dlogger to collect data in a “circular” buffer.
The buffer fills with data until the maximum number of scans defined by
@MAX_SCANS occurs, and then repeatedly fills again according to the FIFO
technique. The buffer is written to the output file
when the “trigger” event is received. The trigger event is either the
@RELEASE_EVENT or the @STOP_EVENT. If the @MAX_SCANS and the trigger event
are not specified, FIFO logging is not made active. The buffer begins filling
when the @START_EVENT is received, or starts immediately if no @START_EVENT
is specified. Example: @FIFO_LOG_BUGGER Specifying the keyword alone within the
spec file enables the FIFO logging feature. |
|
@FIFO_POST_TRIGGER_INTERVAL |
No |
Specify the length of time to obtain
scans after the FIFO trigger event (stop or release event) has been received.
The 'INTERVAL' keyword has precedence over the 'FIFO_POST_TRIGGER_SCANS'
keyword. If both are specified, the 'FIFO_POST_TRIGGER_INTERVAL' value will
be used. Example: @FIFO_POST_TRIGGER_INTERVAL 5[sec] |
|
@FIFO_POST_TRIGGER_SCANS |
No |
Specify the number of scans to obtain
after the FIFO trigger event (stop or release event) has been received. Example: @FIFO_POST_TRIGGER_SCANS 39 |
|
@FORCE_DIRECT_FILE_WRITE |
No |
Indicates that data should be written
directly to the output file when high data rates are used. Care should be
exercised when using this command with very high data rates so that excessive
CPU time is not used by the dlogger program. Example: @FORCE_DIRECT_FILE_WRITE YES Note: if no value follows the keyword,
then a value of “YES” is assumed. |
|
@FTP_EVENT |
No |
Specifies the CyFlex event that will be
set to cause the output file to be “finalized.” This initiates the transfer
of the dlogger output data file
to the /ready directory. The
default is FTP_write. Example: @FTP_EVENT ftp_log_data |
|
@GET_NEW_SCAN_INTERVAL |
No |
The name of an event that can be used to
trigger a re-evaluation of the SCAN_INTERVAL computed expression. Example: @GET_NEW_SCAN_INTERVAL New_dlog_intvl If the event does not exist when the dlogger task is started, dlogger can create the
event. |
|
@GROUP |
Yes |
Label of CyFlex String variable that
contains the measurement name to include in the output file meta-data GROUP='<value>' |
|
@LOG_DIGITAL_DESCP |
No |
This keyword causes the LOGICAL_VARIABLE
descriptions to be logged for all LOGICAL_VARIABLES in place of the values
‘0’ or ‘1’. The keyword can have an
entry following it of either ‘yes’ or ‘no’.
If no entry follows this keyword the value of ‘yes’ is assumed. Example: @LOG_DIGITAL_DESCP Yes |
|
@LOG_STATISTICS |
No |
Specifies that statistics should be
computed for the variables specified via the @SCAN_LIST keyword. The
statistical variables are created locally and are not available to any other
process. Data collection begins with
the start event (@START_EVENT keyword) and is collected at the rate specified
by the @SCAN_INTERVAL keyword. The statistical values are logged to the
output file when a stop event (@STOP_EVENT) is received or the maximum number
of samples (@MAX_STATISTICAL_SCANS keyword) have been collected. This also
stops the data collection. By default, the average value, AV member
of the statistical variable, is logged; however, additional members may be
logged. (See @SCAN_LIST keyword). When another start event is received, all
statistical buffers are reset and the data collection process begins again. NOTE:
If another start event is received before a stop event is received or the
maximum number of scans is reached, then no output is produced. The variables are reset and the data
collection begins again. Example: @LOG_STATISTICS YES |
|
@LOGGING_ACTIVE
LABEL |
No |
The name of a CyFlex Logical variable
that indicates dlogger is actively
collecting data and logging it. @LOGGING_ACTIVE_LABEL Loger_collecting |
|
@MAX_SCANS |
No |
The maximum number of samples in a
sampling session. A zero value or the keyword being absent indicates a
sampling session will continue until a stop_event is received. Example: @MAX_SCANS 1000 When this scan count is reached, data is
moved from the output directory (/logging)
to a “sibling” directory (/ready). |
|
@MAX_STATISTICAL_SCANS |
No |
Specifies the maximum number of scans
when the @LOG_STATISTICS keyword is specified. Example: @MAX_STATISTICAL_SCANS 1000 This causes statistics to be calculated
when 1000 scans have completed. |
|
@MODE |
Yes |
Label of CyFlex String variable that
contains the test mode to include in the output file meta-data
MODE='<value>' Example: @MODE test_mode |
|
@OUTPUT_PATH |
No |
The directory path that specifies where
the output file should be written. If this keyword is absent, then the
default path is: /data/dlog/logging. Example: @OUTPUT_PATH /data/my_data This can be a
string variable that contains the directory path for the output file. The
directories, /logging/ready and /logging/complete, must exist in the specified
directory or the dlogger task will
not start properly. |
|
@PROGRAM |
Yes |
Label of CyFlex string variable that
contains the program name to include in the output file meta-data
PROGRAM='<value>' Example: @PROGRAM prog_proj |
|
@READ_SPEC_FILE_EVENT |
No |
The name of an event that, when it is
received by dlogger, causes dlogger to re-read the spec file. @READ_SPEC_FILE_EVENT read_it |
|
@REG_NAME |
No |
The name that registers the instance of dlogger with the OS. The name must be unique
throughout out the system or the task will fail to initialize correctly. Example: @REG_NAME CVS_FTP75 |
|
@RELEASE_EVENT |
No |
The name of the event that signals the
end of a sampling interval, and terminates the dlogger task after the
data file was written. Example: @RELEASE_EVENT release_dlog When this is received, data is moved from
the output location to a “sibling” directory, /ready. |
|
@RUNNING_AVERAGE |
No |
Specify the window width of a running average and
the event that causes the data to be logged. This keyword causes statistics to be computed for
the variables specified via the @SCAN_LIST keyword. The variables are created locally and are
not available to any other process. The statistics are computed for the specified
window width and continue to be computed as long as data collection is
active. The total number of data points making up the running average is a
function of the window width and the scan interval as specified by the
@SCAN_INTERVAL keyword. Computed expressions are allowed for the window
width specification. The values are logged to the output file
whenever the specified ‘log data event’ is received. By default, the average
(AV) member is logged; however, additional members may be logged. (See
@SCAN_LIST keyword). Example: @RUNNING_AVERAGE # window width log data event 30[sec] log_average_data |
|
@SCAN_INTERVAL |
Yes |
The time between lines of data in the
output file. Example: @SCAN_INTERVAL 0.20[sec] OR @SCAN_INTERVAL Variable_name Note:
Scan intervals that are less than one second cause data to be saved in
memory and written to the output file until a stop_event is received or the @MAX_SCANS value is reached. This
feature can be overridden with the @FORCE_DIRECT_FILE_WRITE keyword (mentioned
later in this table). If the SCAN_INTERVAL is entered as a
computed expression, the expression is evaluated each time that the
START_EVENT is set. |
|
@SCAN_LIST |
Yes |
This is the list
of variables that are to be sampled. Each variable specified may have units
specified, and/or a statistical member, and/or a LOG_DIGITAL_DESCRIPTION
keyword for logical variables. Each variable must include a DARTS (PAM)
keyword. Statistical members are valid only if the @LOG_STATISTICS or
@RUNNING_AVERAGE keyword was specified before the SCAN_LIST keyword is
processed. The statistics
are computed internally and are not the values of any CyFlex statistical
variable. Variables to be sampled are listed in
this format: @ SCAN_LIST <variable> <DARTS KEYWORD> Variables (“labels”) and their corresponding DARTS keywords
are defined as follows: label_1 <DARTS_KEYWORD1> This is the CyFlex variable to be logged
and the corresponding PAM keyword written to the data header of the output
file. label_2[units] <DARTS_KEYWORD2> Optionally, units
may be specified for each label. label_2 .MX <DARTS_KEYWORD3> A statistical
member may be specified when either @LOG_STATISTICS or the @RUNNING_AVERAGE
keyword is specified label_3
LOG_DIGITAL_DESCP <DARTS_KEYWORD4> Label_3 is a
logical variable and the description will be logged instead of a ‘0’ or ‘1’. Note: The optional units, statistical member and
LOG_DIGITAL_DESCP shown above may be specified in any order. If units are
specified, they must immediately follow the label name and be enclosed in [brackets] Example 1: @SCAN_LIST int_mnf_T <DARTS_KEYWORD1> int_mnf_p[in_hg] <DARTS_ KEYWORD2> The
above will log ‘int_mnf_p’ in units of ‘inches of mercury’. Note: When specifying the units, there should not
be a space between the variable name and the specified units of [in_hg]. Example 2: @SCAN_LIST int_mnf_t <DARTS_KEYWORD1> int_mnf_t .MX <DARTS_KEYWORD2> int.mnf_t .SD <DARTS_KEYWORD3> If
the @LOG_STATISTICS or @RUNNING_AVERAGE keyword was specified, then the
values logged are different than described above. If the @LOG_STATISTICS
keyword was specified and the scan list is that shown in example 2, the log
file will contain the average value of
the parameter ‘int_mnf_t’ as the first value and will have the maximum
value of the parameter ‘int_mnf_t’ as the second value. The maximum value
member was specified by entering the standard two-character CyFlex
statistical variable member preceded by a period, and also needs to be
separated from the root variable label by a space.(Refer to keywords
@LOG_STATISTICS and @RUNNING_AVERAGE below for more information). Example
3: If
the specified variable that is being logged is a LOGICAL_VARIABLE, the
logical description may be logged in place of the values ‘0’ or ‘1’. For
example, if the following channel specification is an entry under the
@SCAN_LIST keyword, enab_lwr_lmt LOG_DIGITAL_DESCP <PAM_KEYWORD5> the
LOGICAL_VARIABLE description of enab_lwr_lmt will be logged in place of the
values ‘0’ or ‘1’. The entry must be
exactly LOG_DIGITAL_DESCP or the logical description will not be logged. |
|
@START_EVENT |
No |
The name of an event that signals the
start of a sampling interval. Example: @START_EVENT start_logging |
|
@STOP_EVENT |
No |
The name of an event that signals the end
of a sampling interval. Example: @STOP_EVENT stop_logging When this is received, data is moved from
the output location to a “sibling” directory, /ready. |
|
@SYNC_EVENT |
No |
The name of an event that can be used to
trigger a scan of all channels, usually as an alternative to sampling at a
periodic interval. If both
@SCAN_INTERVAL and @SYNC_EVENT are specified, the sync scans and interval
scans are interlaced. Example: @SYNC_EVENT log_now |
|
@TEST_ID |
Yes |
Label of a CyFlex string variable that
contains the test ID to include in the output file meta-data TEST_ID='<value>' Example: @TEST_ID test_id |
|
@TEST_TYPE |
Yes |
Label of CyFlex string variable that
contains the test name to include in the output file meta-data
TEST_TYPE='<value>' Example: @TEST_TYPE test_type |
Computed
expressions may be used in dlogger specification files.
A computed
expression allows the user to specify the value of a variable as a function of
other variables in the system. The user may create a variable and assign it a
computed expression. The variable value is then computed by CyFlex based on the
expression that the user supplies, which arithmetically combines other variable
values.
The following specification
file keywords support computed expressions:
Guidelines
for using computed expressions and strings in keywords:
Example:
@DESCRIPTION
“ ’Engine model = ‘ + model + ‘ S/N
= ‘ + serial”
If the CyFlex
string variable <model> had a value of <Enforcer 02>, and the
string variable <serial> had a value of <14014957>, the test
description (@DESCRIPTION keyword) for the dlogger file equals:
Engine model = Enforcer 02 S/N =
14014957
Computed
expressions, strings and the variable types that may be assigned a computed
expression are described in a separate document titled, CyFlex Variables, Units, Computed Expressions.
Documents are
available from CyberMetrix that explain CyFlex and related topics, including:
· Cell Utilization,
MSU, and Reporting
· Control Systems
· CyFlex System
Applications
· CyFlex User
Interface
· Data Collection and
Logging
· Data Display
· ECM Communications
· Emissions
Computations and Communications
· Events
· Fluid Composition
and Properties
· Fluid Flow
Computations
· Input and Output
Systems
· Installation Guides
· Inter-nodal
Communications
· Legacy ASSET
Documentation
· Limits Monitoring
· Sensor Calibration
and Reporting
· Smart Instruments
· Statistical
Variables and Sampling
· Technical Reference
· Test Manager
· User Computations
· Utilities and User
Commands
· Variables, Units,
and Computed Expressions
The documents
mentioned above are available for viewing on the Cummins Engineering Wiki, at: http://acizslpapp005.aciz.cummins.com:8005/display/glod/CyFlex+Documentation
This document was
revised as shown below.
|
Document Version |
Reason for Change |
|
1.0 |
New document |
The document
version is always a whole number and increments one number for each new version.
For example, version 1.0 becomes version 2.0.
The version number
increments for a change to either of the following:
· Technical content
· Formatting, unless
the change is minor and does not affect a page break
When a document is
versioned, the version number is updated in the document footer and in the Revision
History table.