GE IMP2B 数据表
Configuration Options
Once MPE has executed, instructions for
further tests, both locally and system-wide,
are taken from a list of system descriptor
items stored in non-volatile memory. This
list can be manipulated from the interactive
System Description Environment (SDE).
System descriptor items can be inserted
or deleted, or existing items modified.
Each item describes a board to be tested
(including the local card), along with test
and reporting characteristics and a test
mask specifying which individual tests
should be run on any particular card.
Descriptor items for unintelligent cards and
also items to invoke custom tests can be
created. A Memory Descriptor Environment
(MDE) performs a similar function to the
SDE, but allows system-wide descriptor
items of memory areas to be tested.
further tests, both locally and system-wide,
are taken from a list of system descriptor
items stored in non-volatile memory. This
list can be manipulated from the interactive
System Description Environment (SDE).
System descriptor items can be inserted
or deleted, or existing items modified.
Each item describes a board to be tested
(including the local card), along with test
and reporting characteristics and a test
mask specifying which individual tests
should be run on any particular card.
Descriptor items for unintelligent cards and
also items to invoke custom tests can be
created. A Memory Descriptor Environment
(MDE) performs a similar function to the
SDE, but allows system-wide descriptor
items of memory areas to be tested.
This flexibility allows tests to easily be tailored
to individual card hardware options and
particular system mixes of cards. Deployed
test of GE Intelligent Platform hardware
genuinely falls within the scope of a true
COTS software test package, avoiding much
of the ‘test integration’ overheads of non-modular
packages, even easing system test integration
when non-GE Intelligent Platform elements
are included as part of the total system.
to individual card hardware options and
particular system mixes of cards. Deployed
test of GE Intelligent Platform hardware
genuinely falls within the scope of a true
COTS software test package, avoiding much
of the ‘test integration’ overheads of non-modular
packages, even easing system test integration
when non-GE Intelligent Platform elements
are included as part of the total system.
BCS Operation
To satisfy the needs of both deployed systems
and development scenarios, BCS is provided
in a flexible form. For instance, in the
VxWorks targeted version the BCS object
module can be downloaded from a
VxWorks target shell, or alternatively it can
be linked to the VxWorks operating system
image.
and development scenarios, BCS is provided
in a flexible form. For instance, in the
VxWorks targeted version the BCS object
module can be downloaded from a
VxWorks target shell, or alternatively it can
be linked to the VxWorks operating system
image.
BCS can also be launched from the target
shell or from an application via insertion of
an appropriate line of code which calls the
start point. It can be statically configured
by altering ‘.h’ files and recompiling, or
dynamically configured at run time via an
interactive menu. Use of all these options is
covered in the user documentation.
shell or from an application via insertion of
an appropriate line of code which calls the
start point. It can be statically configured
by altering ‘.h’ files and recompiling, or
dynamically configured at run time via an
interactive menu. Use of all these options is
covered in the user documentation.
Configuration options include test masks
to enable or disable specific tests, error
logging actions (including enable of visual
indication) and BCS task thread priority.
Typically, BCS would be set to the lowest
priority so that processor cycles are only
used in gaining test confidence when there
is no direct application work to do.
to enable or disable specific tests, error
logging actions (including enable of visual
indication) and BCS task thread priority.
Typically, BCS would be set to the lowest
priority so that processor cycles are only
used in gaining test confidence when there
is no direct application work to do.
BCS is engineered for minimum system
impact, at version 2.0 imposing only 1.2uS
interrupt latency (measured on a PPC4A
with 750 processor @ 250 MHz and 83
MHz bus). Periodicity of background tests
is configurable. Background Flash integrity
tests are accomplished sector by sector,
but it typically takes about 0.5 seconds per
megabyte to verify checksums (depends on
processor speed chosen etc.). Some Flash
access latency is imposed on the sector
BCS is checking. BCS provides a continuous
warning of system problems with the mini-
mal intrusion necessary for use with open
market COTS software components.
impact, at version 2.0 imposing only 1.2uS
interrupt latency (measured on a PPC4A
with 750 processor @ 250 MHz and 83
MHz bus). Periodicity of background tests
is configurable. Background Flash integrity
tests are accomplished sector by sector,
but it typically takes about 0.5 seconds per
megabyte to verify checksums (depends on
processor speed chosen etc.). Some Flash
access latency is imposed on the sector
BCS is checking. BCS provides a continuous
warning of system problems with the mini-
mal intrusion necessary for use with open
market COTS software components.
BCS Features
• Downloadable or linkable to VxWorks
OS image
• HLaunched from shell or application
• Static configuration via .h file
• Dynamic configuration via interactive menu
• Configurable thread priority and other
• Static configuration via .h file
• Dynamic configuration via interactive menu
• Configurable thread priority and other
parameters
• Error log in Flash and visual indication
• Call-back menu for immediate invocation
• Call-back menu for immediate invocation
of individual tests, in addition to running
tests in background mode
tests in background mode
• Logs and scrubs single bit errors
• Comprehensive main memory test. By
• Comprehensive main memory test. By
dedicating small segments per bank for
exclusive BCS usage, and in conjunction
with ECC circuitry, all failure modes
throughout all the memory can be
detected without destructive action
outside the BCS segments
exclusive BCS usage, and in conjunction
with ECC circuitry, all failure modes
throughout all the memory can be
detected without destructive action
outside the BCS segments
• System and user background Flash
checksumming
• NVRAM checksum
• PCIbus error condition monitoring
• Preset PCI configuration verification
• Temperature monitoring
• Temperature throttling
• Network connectivity
• SCSI connectivity
• Bus memory probing
• Real-time Clock test
• Global hardware register verification
• Tests of 8250-compatible COM port
• PCIbus error condition monitoring
• Preset PCI configuration verification
• Temperature monitoring
• Temperature throttling
• Network connectivity
• SCSI connectivity
• Bus memory probing
• Real-time Clock test
• Global hardware register verification
• Tests of 8250-compatible COM port
devices
• AltiVec and FPU tests
• Custom tests can be integrated
• Custom tests can be integrated
Deployed Test Solutions
BIT Features
• Automatic invocation of pre-configured
test set
• Layered tests for best subsystem isolation
• Interactive configuration environment
• Interactive test invocation environment
• Object product recognizes and runs
• Interactive configuration environment
• Interactive test invocation environment
• Object product recognizes and runs
custom PMC tests written to recom-
mended format
mended format
• Visual indication and detailed results
stored in Flash or system RAM for later
analysis
analysis
• BIT co-ordinates test execution and
results throughout all GE Intelligent Plat-
form boards in a system
form boards in a system
• 95% or greater functionally verifiable
coverage
• In addition to internal node tests,
optional edge node tests allow the
use of BIT for ATP as well as deployment
optional edge node tests allow the
use of BIT for ATP as well as deployment
Bit Coverage Verification
Standard reliability analysis figures are
traditionally used to help determine test
firmware coverage. Either a parts count or
parts stress failure rate prediction will produce
a table of the number of failures per million
hours for each component. Every figure
in this table can be given a weighting that
would contribute to an overall coverage figure
for all parts that the firmware actually
tests.However, this method has a number
of drawbacks. First, data from actual field
failures does not always align well with
failure rate predictions. Second, since the
full acceptance of COTS technology, there is
now a broad range of sources of data used
for reliability prediction. Any test firmware
coverage based only upon reliability analysis
tends to be more dependent on the sources
of the failure rate data used than on the
quality of the firmware implementation.
Last, only the very latest failure rate prediction
methodologies are beginning to take into
account the significant effect of printed
circuit board and solder joint reliability.
traditionally used to help determine test
firmware coverage. Either a parts count or
parts stress failure rate prediction will produce
a table of the number of failures per million
hours for each component. Every figure
in this table can be given a weighting that
would contribute to an overall coverage figure
for all parts that the firmware actually
tests.However, this method has a number
of drawbacks. First, data from actual field
failures does not always align well with
failure rate predictions. Second, since the
full acceptance of COTS technology, there is
now a broad range of sources of data used
for reliability prediction. Any test firmware
coverage based only upon reliability analysis
tends to be more dependent on the sources
of the failure rate data used than on the
quality of the firmware implementation.
Last, only the very latest failure rate prediction
methodologies are beginning to take into
account the significant effect of printed
circuit board and solder joint reliability.
GE Intelligent Platform still provides traditional
reliability analysis figures (generally to MIL-
STD-217), which is certainly useful data to
have when considering the overall suitabil-
ity of particular boards for mission-critical
applications. However, in the highly com-
mercial world of COTS silicon, this method
no longer furnishes a reliable or objective
measure of test firmware coverage. More-
over, it does not predict failure due to
mis-handling problems or interface abuse.
This can be important, considering the
advent of COTS has meant an increasing
reliability analysis figures (generally to MIL-
STD-217), which is certainly useful data to
have when considering the overall suitabil-
ity of particular boards for mission-critical
applications. However, in the highly com-
mercial world of COTS silicon, this method
no longer furnishes a reliable or objective
measure of test firmware coverage. More-
over, it does not predict failure due to
mis-handling problems or interface abuse.
This can be important, considering the
advent of COTS has meant an increasing