**Minutes of the 5th RIA/NIST Workshop on Open Architecture Control in
Robotics**

Wednesday 9 January 2002

FANUC Robotics North America

Rochester Hills, MI

Fred Proctor, NIST

This was the fifth meeting in the series of open architecture robotics
workshops sponsored by the Robotic Industries Association (RIA) and the
National Institute of Standards and Technology (NIST). In attendance
were Fabrice Ciccarelli (Nachi Robotics); Fred Proctor and Jim Gilsinn
(NIST); Jeff Fryman (RIA); Larry Hamilton, Clif Triplett, Jim Wells,
Gary Workman, Andy Hamor and Jim Heaton (General Motors); Claude
Dinsmoor (FANUC), Lee Featherstone (IAONA/Jetter) and Bill Kneifel (KUKA
Development Labs).

The meeting began with a discussion of Dave Gravel's email on the
reaction of Ford's purchasing to the Wave 1 Technical Report (Dave was
not present at the meeting). Dave wrote:

*"The status I would like to report to you is that GM and Ford did meet
on April 12, 2001 regarding a proposed change of Ford robot purchasing
specifications. In attendance from the Ford side were myself, John Eyes,
Richard Jent, and Marion Griffin. GM proposed that Ford also add
purchasing language to specify TCP/IP and FTP protocols, 802.3 data
layer, and Cat 5 wiring as a standard. These were viewed as a minimal
set of specifications that could one day lead to the vision of XML style
sheets to make any controllers interface to the web and look similar. On
an immediate practical plant floor level it would enable automatic
backup, download, enhanced disaster recovery, and change control of
programs to be tracked (upload/download file compare). Ford agreed to
consider revising its purchasing specification to add these, similar to
GM, to create an ad-hoc industry standard.*

*"Since that meeting, not much progress has been made to change the Ford
robot purchasing specification. I believe there may be some apprehension
about potential effect of robot pricing if these specifications are
added. I believe everyone at Ford shares the vision of using advanced
information technology to enhance productivity, but the pressures to
control costs are huge. Has GM incurred a price increase because of this
additional specification?*

*"Perhaps the next step is to see if we can get the robot suppliers in
the RIA 15.04 group such as Kuka, FANUC, and Motoman to agree that this
would not add cost to the robot units. I think we stand a better chance
to make this purchasing specification change at Ford if this issue was
put to rest."*

Claude Dinsmoor raised the point that robot costs will not necessarily
remain the same or be reduced, since more hardware and software will be
present. The cost is presumed to be small relative to the benefit to the
end user of standard networking hardware and software. The group agreed
that the R15.04 Technical Report should include a Forward that states
this, so that end users who purchase robots will understand it. **Fred
Proctor volunteered to draft the Forward and circulate it to the R15.04
committee via the web board.**

The group noted that the big end-users should agree on standard
purchasing language so that the Technical Report will make it into
procurements. This should be easier with the proposed Forward. Several
members volunteered to stump for the Technical Report to targeted
audiences. **Clif Triplett volunteered to enlist Toyota, Jeff Fryman for
Mitsubishi and Honda.** DaimlerChrysler remains elusive. Tom Lasorda of
DaimlerChrysler may be a candidate. **Clif will look into enlisting a
DaimlerChrysler person.**

Vendors need a similar agreement, which the group thought could take the
form of a letter of endorsement. The letter would state support for the
concept of unification on a small set of common interface standards, in
order to better support customer needs for interoperability and reduced
time to market. The letter would also state that vendors believe in the
potential for increased robot sales. RIA would circulate the letter,
possibly as a press release. **Fred Proctor volunteered to draft the
letter and forward it to RIA.**

In addition to adding a Forward, other modifications to the Technical
Report were discussed. Table 1 will be changed so that the statement "no
implementation" for the Presentation and Session layers will be replaced
with "no current specification". **Fred will make this change.** Fred
also reviewed the recent change history arising from the Fanuc/Kuka
edits and Fred's responses, which were posted to the RIA web board.
**Claude Dinsmoor, Bill Kneifel and Fabrice Ciccarelli agreed to review
this and post comments to the web board.**

Jim Wells and Andy Hamor presented their work on robot support for
Ethernet/IP at General Motors (this and all presentations are on the web
site, www.isd.mel.nist.gov/projects/openarch, under Past Meetings). In
summary, they presented the current controls architecture for body shop
applications, which supports three networks: DeviceNet within a cell,
ControlNet between cells, and Ethernet for whole-plant connectivity and
beyond. In Phase I of their upgrade plans, they will replace ControlNet
with Ethernet/IP. This will not affect robot controller communication.
If the Phase I pilot is successful, GM plans on expanding Ethernet/IP to
include robot controllers, weld controllers, tag readers, and vision
inspection systems. This will impact the robot controller. Beyond this
Phase II pilot, GM will explore smart process interfaces, predictive
maintenance and diagnostics, and SNMP MIB for robot controllers.

The group moved into a discussion of security issues. According to Jim
Heaton, GM currently uses VLANs and address filtering at switches.
Eventually they expect to move to IPV6 and IPSec. Jim made the statement
that "99% of this will happen outside the robot controller, 1% within."
We expect that IPV6 and 100 Mbps wireless will arrive at about the same
time, which will mark the beginning of widespread wireless adoption
since both security and speed will be improved.

IPV6 also supports quality of service, which the group has maintained is
necessary for real-time control over Ethernet. Jim Heaton said that GM
uses Cisco switches with a proprietary QoS implementation that can
prioritize packets based on MAC address and header information
selectively. Devices need not be aware of any QoS protocol, for a
transparent solution.

Jim Wells made the interesting point that self-diagnostics are more
important for reliable systems than for unreliable systems. With
unreliable systems, diagnostics tools are run frequently enough that
production staff remain familiar with them and can use the effectively.
With reliable systems, memories of troubleshooting fade over time, and
each problem is a fresh one.

Gary Workman of GM gave a series of presentations on Ethernet/IP and
GM's implementation plans. He first explained Ethernet/IP, and gave an
update on the Ethernet/IP Implementers Workshop Planning Seminar. He
continued with a presentation on GM's future architecture and vision.
Gary explained his view of Ethernet/IP as "control system traffic
preemptively sharing the node's bandwidth with information systems
traffic." Following the pilot sequence laid out by Jim Wells in the
preceding presentation, Gary said that for Phase I, GM
Controls/Robotics/Welding will adopt Ethernet/IP for PLCs when the pilot
is successful, and the cost of Ethernet/IP is not more than the cost of
ControlNet. Pilot success means two months of operation with no
problems. Gary emphasized that in Phase I, there are 10 cells, connected
with Rockwell Ethernet/IP (single vendor), whose function is to
transport interlocking signals. Regarding PLCs in general, Gary noted
that GM/CRW uses only Rockwell PLCs. The cost of the PLC itself is
inconsequential when compared with the programming environment, less
than 10% of the total cost. GM Powertrain, on the other hand, uses soft
PLCs, or Siemens PLCs globally. In turnkey systems the PLC is
internalized and is ad hoc, typically Bosch or similar.

For Phase II, Gary said that GM CRW will adopt Ethernet/IP for robots
when the pilot is successful, the cost for an Ethernet/IP upgrade from
the robot vendor is not more than the cost for a DeviceNet slave
interface, and ODVA-conforming products are available from all robot
suppliers. Ethernet/IP will be adopted for weld controllers following
similar criteria, in this case when Ethernet/IP is supported on PLCs and
robot controllers, and when the cost is not more than the cost of a
DeviceNet interface plus the RS-422 proprietary interface.

At the I/O level, GM CRW will adopt Ethernet/IP when it's supported on
PLCs and robots, an industrial connector is available, and the cost of
Ethernet/IP plus the cost to power the device is not more than the cost
of DeviceNet (except for devices with large data content, such as vision
equipment). Jim Heaton noted that powered Ethernet is becoming more
popular for communication applications, where devices such as switches
don't need a separate power cord and can be put away in ceilings. The
power supplied was thought to be in the 48V - 300 milliamp range.

Gary concluded with a proposal by Kuka to set up an Ethernet Demo Cell
in the Detroit area. This would be a duplicate of a cell in Germany,
which contains four robots in a typical body shop environment. The cell
uses Ethernet exclusively, even on the device level. The project started
with the preliminary IDA protocol, and Kuka plans to implement other
protocols as well. Each device contains an embedded web server, and the
robots also support OPC, NTP (network time protocol), FTP, with PTP
(precision time protocol) planned. The demo cell would not include robot
equipment from vendors other than Kuka, so for interoperability tests
between robot vendors something like the GM pilots need to be done.

Lee Featherstone of IAONA gave a presentation on his group, describing
their work on industrial Ethernet. IAONA is a vendor-neutral
specification that supports hard real-time Ethernet. The group takes
into account current standardization activities, e.g., solutions must
comply with the IDA/Ethernet/IP specification. There are several groups
in IAONA. The System Aspects Group is investigating IP addressing, plug
and play, network management and security. The Wiring and Infrastructure
group is defining international requirements for industrial wiring for
both copper and fiber optic. The Safety Aspects group is analyzing
Ethernet safety solutions and evaluating possible harmonization of these
solutions. To date, IAONA has completed a Wiring and Installations
Guideline; set up CENELEC and IEC working groups, and launched a wiring
standard.

Bill Kneifel suggested that we firm up a relationship with IAONA, since
they've done a lot of work with industrial Ethernet that we don't want
to do again.

We revisited the roadmap for the three-wave standards rollout, since
there continues to be confusion about what standard is in what wave.
Here is the current matrix, courtesy of Claude Dinsmoor who put up a
past working group presentation and made edits suggested by the
participants. **Fred Proctor will web-ify the Wave Table and put it on
the openarch web site.**

  ----------------------- ----------------------- -----------------------
  **Wave 1**              **Wave 2**              **Wave 3**

  Ethernet 10/100, RJ 45  DNS                     BOOTP/TFTP
  connector                                       

  TCP/IP                  DHCP client             SNMP/MIB-II

  FTP                     Time Protocol (NTP,     HTTP
                          TNTP, PTP to be         
                          determined)             

                          UDP                     HTML

                                                  XML/XSL

                                                  UDP with QOS

                                                  Real-Time Ethernet
                                                  Implementation
                                                  Guidelines
  ----------------------- ----------------------- -----------------------

Wave 1 is no surprise since it's in the R15.04 Technical Report. Wave 2
is characterized as "those facilities and standards that allow robots to
interact with larger networks and in a networked environment better."
DNS (Domain Name Service) means that the robot controller is configured
to use DNS to look up host names to get IP addresses, rather than using
a local host file. DHCP client means that the robot's IP address is not
statically assigned, but is looked up by querying a DHCP server. UDP
(the connectionless datagram) means the robot controller supports UDP,
which in the short term supports network equipment with ad hoc support
for packet prioritization and is also required for DNS and DHCP. The
Time Protocols are still under consideration. We originally put NTP,
Network Time Protocol, but during the meeting it was suggested that this
may be overkill. NTP can reference up to five time sources, analyze
latency, and do convergence to get a better time estimate. Other time
protocols may be more suitable, e.g., TNTP (Trivial NTP) or PTP
(Precision Time Protocol). The timing for Wave 2 is sometime in 2002.

Wave 3 has four categories. Medialess operating system loading via
network connections means using BOOTP and TFTP (Boot Protocol, Trivial
FTP) to get the boot image off a network server, so that the robot
controller has no local disk. Device Management means using SNMP/MIB-II
to manage the network configuration of the robot controller remotely.
Data abstraction and presentation include HTTP, HTML, and XML/XSL. For
robot controllers, this means running an HTTP server, and providing HTML
web information, and conforming to an XML definition for controller
information that this group will develop. The final category is
real-time communication over Ethernet. This includes UDP with QOS
(Quality of Service). Additionally, the group will write guidelines for
implementing a real-time Ethernet environment, layout out recommended
network architecture and topology.

Claude Dinsmoor made the point that we need metrics on acceptance of the
R15.04 reports, market penetration of conforming products, and impact.
The results will be used to guide marketing, determine the need for
technical work, address economic barriers, and gate Wave 3 work.

The schedule for the final release of the R15.04 Wave 1 technical report
is as follows. Fred Proctor will rewrite according to the changes noted
earlier, then post to the RIA web board for committee comment and
revision. RIA will review the report, which according to Jeff Fryman is
a relatively quick process, then it goes to ANSI for a review that takes
about 30 days. We should have this all done prior to the next meeting,
sometime in June. At that meeting, we will review our promotion of the
report and decide how to improve it. The committee should also come to
the June meeting with a Wave 2 draft prepared.