|
Conformance tests for DeviceNet
As the number
of DeviceNet installations rapidly grows, so the importance of conformity
of devices to a standard increases. Richard McLaughlin outlines
conformance testing procedures
By the end of
1995, there were 5,000 Device-Net nodes installed. A year later,
that number had increased to 50,000, and 1997 saw the installations
top 150,000. That number continued to grow through the end of the
nineties, and it's growing still. With this rapid growth of DeviceNet
implementations, and with large numbers of vendors developing DeviceNet
products, the need for a centralised conformance test procedure
is crucial.
All devices
bearing the name DeviceNet must strictly follow the DeviceNet specification
in order to achieve device interoperability in an open standard
network. Conformance to the DeviceNet specification can only be
achieved if the same test plans or procedures are followed. It is
in the interests of the ODVA and every device developer to prevent
the scenario where vendor X's device upsets the DeviceNet network
operations.
The ODVA Conformance
Test Special Interest Group (SIG) has produced a suite of conformance
test software products, and established conformance test certification
sites, one of which is at the University of Warwick. Developers
are encouraged to utilise the conformance test software in-house
during product development. This ensures that the end product will
have little or no problems during conformance certification at one
of the conformance test centres. In order to ensure smooth operation,
Conformance SIG has listed out a series of procedures to be followed
by developers. These are:
- Purchase
a DeviceNet Specification
- Register
with the ODVA to obtain a Vendor ID
- Attend the
Developers' Training if necessary
- Purchase
the sample source code, if necessary
- Purchase
the field test version of the conformance test software, if necessary
- Develop
the product. At this stage, product developers are advised to
discuss with the Conformance SIG for any problems found. This
may help to speed up the problem solving, and identify any confusion
in the specification
- Order independent
conformance testing from the ODVA
- Arrange
with the independent test laboratories the date of testing
- Prepare
a Statement of Conformance, SOC, in digital format (part of the
conformance test software)
- Submit the
device for the test. It is recommended that the programmer who
was involved in the development of the DeviceNet product should
be present in order to discuss any problems found, and remedy
problems on the spot.
BOX: Common
pitfalls affecting conformance testing
Message wait
times set-up During the setting up of the conformance test, there
is an option where the message wait times must be set. There are
currently two types: Minimum and maximum wait times for explicit
and I/O messages. Minimum wait times are required by the DeviceNet
device to perform a series of set-ups before the transmission of
CAN messages takes place. Maximum wait time is the maximum delay
time allowed for the device to respond to the request message.
Firmware The
product can not be claimed to be DeviceNet compliant unless it is
a fully assembled product tested and passed by the conformance test
software. Any products that use third party firmware cannot claim
to be DeviceNet compliant until fully tested and passed by the test
software, even though the third party firmware is DeviceNet compliant.
Field Test
software As concluded by the DeviceNet Conformance SIG, the conformance
test software should not be treated as part of the DeviceNet Specification.
Its purpose is to help developers to identify the possible hidden
mistakes that might take place under any unforeseen circumstances
and to improve the reliability of the product against the specification.
Like all other software, the test software might inevitably contain
some bugs. If the developers find problems that can not be explained,
they are advised to reflect the situation and discuss it with the
Conformance SIG rather than modifying the firmware to bypass the
problem. Bypassing the problem may eventually cause the product
to fail the interoperability test.
New released
DeviceNet conformance tests will continue support prior versions
of specification for a period of nine months immediately after the
new version is officially released. After this period, the developers
are advised not to adopt the old version. An exceptional case is
a product that is to be re-tested within a reasonable time scale,
such as one to two months.
Statement of
Conformance The SOC must be compiled correctly and submitted together
with the DUT. The product developers are responsible for generating
the SOC in MS- DOS based digital format, on a 1.44 MB diskette.
Failure to do so may cause the product to fail the test and unnecessarily
waste time debugging or configuring the device. The test laboratory
staff may assist but will not take any responsibility on the failure
of the product testing.
When a DeviceNet
product is developed successfully, it has to undergo a strict conformance
test where all behaviours, or parameters, are tested. This ensures
that the device works correctly with other DeviceNet devices and
does not cause any interoperability problems which may jeopardise
the network.
Predefined
feedback The conformance test is carried out in such a way that
a conformance test engine (a personal computer, a proven CAN interface
card, and the conformance test software) serves as a CAN node issuing
a series of commands to the device under test (DUT), and expects
predefined feedback from the DUT within a predefined time frame.
During conformance
testing, the conformance test engine tries to simulate all possible
situations, verifying the parameters are correct according to the
specifications, including off-line conditions. The test engine records
all test messages (transmitted and received) in a log file for debugging
purposes. Extra comments are generated in the case of error occurring.
Having gone
through a strict conformance test, the product still has to undergo
an interoperability test. The conformance test carries out the test
on a network which has no other nodes on. In this case, it cannot
simulate situation where the network bus loading is high. The impact
on the highly loaded network is that the signal might be delayed
by a significant time. The effect is important, especially on a
Group 2 only device where the communication between the device and
the third party tool is indirect.
In addition,
since the conformance test engine tests only on Application Level,
any physical (electrical or visual) characteristic that is stated
in the SOC must be verified correctly.
In order to
carry out the interoperability test, the device is connected to
a DeviceNet network which is operating at the maximum baud rate
specified on the product's SOC. On the network, a periodic signal
is transmitted onto the bus by another designated node, giving a
highly loaded bus. The timing behaviour of the DUT can then be monitored.
If the DUT does not cause any problems to the network within a specified
time frame, the device passes the interoperability test.
The Conformance
SIG has set recommended interoperability test configurations to
ensure a world-wide standardisation of this test. Also work is ongoing
at Warwick University to explore alternative test configurations.
This will ensure that there is a suite of interoperability tests
to cover all possible device profiles.
The intention
of DeviceNet is to offer highly reliable, low cost, yet intelligent
industrial devices. Strict conformance testing is necessary although
sometimes there seem to be procedures that appear to extend the
development time, such as more time spent to debug a program for
a minor mistake that is 'believed' would not cause any significant
effect when it is connected to the production network. These procedures
are necessary to ensure DeviceNet multi-vendor product interoperability.
Experiences show that most problems are quite simple, and easily
remedied.
Following DeviceNet
conformance test procedures ensures the device will pass the conformance
test with little or no retesting. Possession of the field test version
of the conformance test software will greatly enhance the development
cycle of a new DeviceNet product. It serves as a significant development
tool, and it has the backing of the ODVA Conformance SIG - the Conformance
SIG will help when problems arise. End users will ensure their level
of confidence in DeviceNet products by specifying only those products
that have been conformance tested.
Exploiting innovations
in CAN
Warwick
Control Technologies (WCT) is a new company based in the University
of Warwick Science Park near Coventry. It was launched from
Warwick Manufacturing Group's CAN Laboratory with the initial
aim to commercially exploit two products based upon the intellectual
property developed in the CAN Laboratory.
On product,
X-Analyser, is a low cost but powerful Windows based tool
used to analyse and test the behaviour of CAN and DeviceNet
control systems. X-Analyser has been used in many applications,
from vehicle instrument pack calibration to observation and
calibration of satellite control systems. It allows the user
to send and receive CAN data, along with other features such
as bus statistics, CAN ID tagging, engineering units, advanced
filtering and triggering capabilities. An upgrade option allows
the user to visualise data with Devicenet awareness, with
other higher layer protocols to be supported in the future.
There is a DeviceNet message builder option that allows a
developer to exercise a device (or devices) for testing. Its
easy to use interface should prove attractive to product developers
and end users alike.
WCT has
set up an agreement with Softing in Germany to sell the X-Analyser
through an international network of distributors. Softing
provides a hardware interface for the X-Analyser. WCT is also
working with HM Computing in the UK to release X-Analyser
with its PCI intelligent dual CAN board. HM is also working
on a future compact PCI board.
The second
piece of intellectual property is the patented CAN Bus Load
Transducer Technology, which provides a low cost means of
monitoring the level of CAN bus traffic. This type of technology
is especially useful when developing CAN passenger car control
systems. If there is a failure of a component within these
types of control system, the results can be catastrophic and
even result in the loss of life. Monitoring of CAN bus load
is often neglected in the automotive industry due to the expense
involved. Now, however, this is possible with WCT's new low
cost technology, with the additional costs said to be less
than $0.5 per unit. WCT intends to exploit this technology
by providing technology licences to companies wishing to integrate
it into their products.
WCT is
also carrying out software development services for companies
requiring solutions to distributed control problems, and has
already supplied CAN and DeviceNet solutions to the automotive
and automation sectors. Check out the company's web site at
www.warwickcontrol.com.
|
|
