`
`ABB v ROY-G-BIV
`
`TRIAL IPR2013-00062
`
`ABB - EXHIBIT 1024
`
`Page 1 of 53
`
`

`

`TECHNOLOGIES ENABLING AGILE
`
`MANUFACTURING
`
`(TEAM)
`
`INTELLIGENT CLOSED LOOP PROCESSING
`
`Open Architecture Specification
`
`Part 1: General Information
`
`January 11, 1996
`
`Page 2 of 53
`Page 2 of 53‘
`
`

`

`CONTENTS
`
`FOREWORD
`
`.................................... iv
`
`BACKGROUND ........................................................................................................................................... v
`
`TEAM API SYSTEM ENVIRONMENT .............................................................................................................. vi
`
`TEAM ICLP - OPEN MODULAR ARCHITECTURE CONTROLLER: EXAMPLE ........................ ix
`
`1 GENERAL ..................
`
`.................................
`
`...............
`
`...................
`
`........... 1
`
`
`1.1 SCOPE ...................
`‘
`1.2 OBJECT OF THE SPECIFICATION ................................................................................................................. 1
`1.3 OBJECT OF PARTI .................................................................................................................................... 2
`1.4 NORMATIVE REFERENCES ..........................
`.
`.................................................................................... 2
`
`2 DEFINITIONS .......................................................................................................................................... 3
`
`3 GLOSSARY............................................................................................................................................... 4
`
`4 DEVELOPMENT AND INTEGRATION LIFE CYCLE MODEL ..................................................... 5
`
`4.1 CONTROL COMPONENT SUPPLIERS’ TASKS ............................................................................................... 6
`
`4.1.1 Services Requiredfrom Other Modules ............................................................................................ 7
`4.1.2 Services Provided.............................................................................................................................. 7
`4.1.3 Module SourceCodes ....................................................................................................................... 7
`
`4.1.4 Define Modules & Services ................................................................................................................ 7
`4.1.5 Module Definition .............................................................................................................................. 7
`4.1.6 Binary Modules .................................................................................................................................. 8
`4.2 TEAM API WORKGROUP TASKS ............................................................................................................. 8
`
`4.2.1 Define Classes ..........................................................................._........................................................ 8
`4.3 CONTROL SYSTEM INTEGRATORS’ TASKS... ............................................................................................. 9
`4.3.1 Build Module Database .................................................................................................................. 10
`
`4.3.2 Module Definition Database: .......................................................................................................... 10
`4.3.3 Create Modules ................................................................................................................................ 11
`
`4.3.4 System Module Database ................................................................................................................. 11
`4.3.5 Initialize and Configure Modules .....»............................................................................................... 11
`4.3.6 Create System Resource Model........................................................................................................ 11
`4. 3. 7 System Resource Model .....................................................................................‘.............................. 1 1
`4.3.8 Design System .................................................................................................................................. 11
`4.3.9 System Model ..........................................................................'. ........................................................ 12
`4.3.10 Configure & Integrate System ........................................................................................................ 12 -
`4.3.11 System Capability Database ........................................................................ . ................................. 12
`4.3.12 System Binary Database ................................................................................................................ 12
`4.3.13 System Initialization Database....................................................................................................... 12
`4.4 END USERS’ TASKS ................................................................................................................................ 12
`
`4.4.] Start System ..................................................................................................................................... 13
`4. 4. 2 System Directory ............................................................................................................................. 13
`4. 4. 3 Run System ...................................................................................................................................... 13
`4. 4. 4 Create Application Programs ......................................................................................................... 14
`4. 4. 5 Application Programs ....................'................................................................................................. 14
`
`ANNEX A .................................................................................................................................................... 15
`
`A. 1 CONFIGURATION- BASE AND DERIVED CLASS API STRATEGY- SUBCLASSING .............................. 15
`A. 2 INTEGRATION- MODULE CONNECTIONS .......................................................................................... 17
`
`Page 3 of 53
`Page 3 Of 53
`
`

`

`Foreword
`
`“This draft document has been prepared by the Technologies Enabling Agile Manufacturing
`(TEAM) Intelligent Closed Loop Processing (ICLP) Application Programming Interface (API)
`working group. The TEAM API working group developed a specification that will consist. of the
`following series of documents:
`
`Part 1:
`
`General Information
`
`Part 2: Module Capabilities
`
`Part 3: Module Specification Class Descriptions
`
`Part 4: Module Specification C-H- Header Files
`
`includes a Life Cycle model that describes the steps and actions required to build a
`1
`Part
`controller. The breadth of satisfying Plug-and—Play compatibility is extensive. Not all elements in
`the Life Cycle have been addressed. The focus of the effort has been on defining Application
`Programming Interfaces for certain modules routinely that
`the ICLP community wants to
`upgrade. The TEAM API effort discusses but does NOT attempt to specify procedures for such
`issues as:
`
`—
`
`performance evaluation
`
`— validation, verification
`
`— resource profiling and environment
`
`This specification is scaleable for the system design, integration and programming for systems
`ranging from a single-axis device to a multi-arm robot. The TEAM API working group focus was
`programming requirements for precision machining. Applicability to other control environments
`may be possible but cannot be guaranteed.
`
`Page 4 of 53
`Page 4 of 53
`
`

`

`Background
`
`
`
`
`
`~ Minot (TNT‘, mnh'nn marl diam-an: nnnh-nl annlinafinnc innnmnrafe nrnnriptarv nnntrnl technnlncfles-.-y..— ‘v- - v, ---v--v-- _.-.. unvuwiv vyuuv. arr ..................... r- 'r“""“J v--- _ ow. 0--
`
`that have associated problems: non-common interfaces, higher-integration costs, and specialized
`training. On the other hand, an open--architecture controller is built from multi-vendor,p1ug-
`compatible modules and component parts. The operation to build a controller from module
`components is multi-faceted and includes the following major elements:
`
`— User defines “initial conditions” such as hardware, control devices, and computing
`platforms that in general constitute the application resources.
`.
`
`— Platform supplies system low—level services (e.g., file-management, etc.)
`
`- Integrator connects selected modules together via standard integration and
`configuration techniques.
`
`— Analysis checks compliance of modules to support user-specification of performance
`and timing requirements.
`
`-— Flexibility of modules provides default or minimal functionality where user has not
`selected any.
`
`— Scalability of modules allows convenient methods of experimentation - to reconfigure
`modules quickly; and optionally, capture results in order to analyze the .
`experimentation.
`
`These operations form the basis for the open architecture requirements which are:
`
`Open
`
`Allows the integration of off-the-shelf hardware and software components into a controller
`infrastructure that supports a “de facto” standard environment.
`
`Modular
`
`Refers to the ability of controls users and system integrators to purchase and replace
`components of the controller without adversely affecting the rest of the controller nor
`requiring extended integration engineering effort, permitting “plug and play” of a limited
`number of components for selected controller functions.
`
`Extendible
`
`Refers to the ability of intelligent users and third parties to incrementally add functionality
`to amodule without replacing it completely.
`
`\u,
`
`Page 5 of 53
`Page 5 0f 53
`
`

`

`Portable
`
`Refers to the ease with which a module can run across platforms. Standards such as ANSI
`C and POSIX serve as a reference to which programmers adhere.
`
`Scaleable
`
`Like portability, refers to the ease with which a module can run in a controller based on
`another platform, but unlike portability, scalability allows different performance based on
`the platform selection. Scalability means that a controller may be implemented as easily
`and efficiently by systems integrators on a high-speed processor, as a distributed multi-
`processor system, or on a standalone PC to meet specific application needs.
`
`Maintainable
`
`Supports robust plant floor operation (maximum uptime), expeditious repair (minimal
`downtime), and easy maintenance (extensive support from controller suppliers, small spare
`parts inventory, integrated self-diagnostic and help functions, etc.)
`
`Economical
`
`Allows the manufacturing equipment and systems that the controller controls achieve low
`life cycle cost.
`
`TEAMAPI System Environment
`
`The Open, Modular Architecture Controller (OMAC)1 defines the system requirements for an
`Open-architecture, Application Environment that
`includes Platform and Infrastructure, Core
`Modules, and a standard Application Programming Interface to the Core Modules. Using the
`OMAC model as a baseline, Figure l specifies the modules in a standard environment.
`
`Adhering to the Open Architecture requirements, modules can be added, removed, and extended
`based on the functionality required (extensibility), be replaced by other modules with equivalent
`functionality but at different performance level (scalability ‘& modularity), and are operating
`environment independent (portability).
`
`The modules have the following responsibilities:
`
`Part Program Interpreter
`
`Part Program Interpreters are responsible for translating the part program into control
`sequences.
`'
`
`'.
`
`Initial requirements defined in White Paper jointly co-written by GM, FORD, and Chrysler
`
`Page 6 of 53
`Page 6 of 53 '
`
`

`

`Task Coordinator
`
`Task Coordinators are responsible for sequencing operations and coordinating motion,
`sensing, and event-driven control processes.
`
`I Axis Group
`
`Axis Groups are responsible for coordinating the motions of individual axes.
`
`Part
`Interpreter
`
`Group
`
`
`Axis
`
`
` Task
`
`Coordination
`
`User Defined
`Process
`
`
`
`
`Axis
`
`Human Interface
`Agent
`
`Control Laws
`progress
`
`Discrete
`Control
`
`Axis
`
`Note : Shaded API - work in
`
`Figure 1. Major Module Types
`
`Axis
`
`Axes are responsible for motion control.
`
`Kinematics Model
`
`Kinematics Models are responsible for kinematics configuration, geometric correction,
`thermal compensation, tool offsets, and the effects of tool wear.
`
`Page 7 of 53
`Page 7 of 53
`
`

`

`Control Law
`
`Control Laws are responsible loop closure calculations to close the motion loop.
`
`' Human Interface Agent
`
`Human Interface Agents are responsible for the data access between controller internal
`modules and appropriate mirrored graphical user interface objects in an Operator Interface
`environment outside of the controller.
`
`[/0 Points
`
`I/O Points are responsible for the reading of input devices and writing of the output devices
`through a generic read/write interface.
`~
`
`Communication
`
`Communication modules are responsible for both local area communications and sensor
`effector bus communications.
`
`Page 8 of 53
`Page 8 of 53
`
`

`

`TEAM ICLP - Open Modular Architecture Controller: Example
`
`A: A
`:‘I-—-L..-L-- AL- _--2..- anuu.‘
`’1
`. 13:..-“
`_.....
`Aafl‘dflllflf an flat“! mun“? kn manna-urn
`1 a UUI‘llUllUA an ‘4le AIAIDLAU vv vvannnomw
`1 15wc A utuauatca UIC llldJUl aymuua u
`
`d
`
`numerical control application.
`
` Human
`Interface
`
`
`l/O Point
`Feedrate Override
`
` Task Coordinator
`
`
`
`Part Program
`Interpreter
`
`
`
`
`
`
`‘-
`I ‘
`
`IS on ro
`
`Axis Control 1
`
`5
`
`
`
`
`
` Discrete Logic
`E STOP. Machine Sensors
`
`
` Sensor 1
`
`
`
`
`[/0 Pts
`
`Sensor 2
`
`Mac ine
`
`Sensors
`Status
`
` Amp-Fault
`
` Encoder
`A Quad B + Z
`HWl: One axis power drive, HW2: one axis 4 channel encoder
`
`Figure 2. Example of an Controller
`
`Page 9 of 53
`Page 9 of 53
`
`

`

`The application used for this purpose is programmed numerical control for a two-axis lathe. The
`axis components are assumed be the same for each axis and consist of a PWM motor drive, an
`amplifier enable control, an amplifier fault status signal, an A-QUAD—B encoder with marker
`pulse and switches for home and axis limits. The spindle drive components are assumed to
`. provide a facility for setting spindle speed and direction and to start and stop spindle rotation.
`The machine sensor system is assumed to consist of a set of analog and digital sensors
`monitoring coolant temperature and oil pressure. The machine safety system is assumed to
`consist of a set of input switches monitoring E-Stop, Power-Up and Reset. The control pendant is
`assumed to provide an operator with a simple set of control functions including part program
`selection, Cycle Start/Stop, Feedhold, Feedrate Override, Manual Data Input and Manual
`Jogging. The machine part programs are assumed to be in EIA RSZ74D format. The control
`pendant is assumed to display machine status to an operator including indication, machine
`modes, program status and machine diagnostics.
`-
`
`This application is used as a reference example for open architecture modular controllers. Some
`possible modifications to the reference application that would be instructive are:
`
`0 add tachometer feedback to the axes/add IO modules/control loop module;
`
`0 use SERCOS drive instead of PWM/replace IO modules/replace control loop module;
`
`0 add secondary linear slide/add IO modules/add control loop module/ replace axis group
`module;
`
`0 add spindle position control/add IO modules/add control module/replace axis group
`module;
`
`0 add tool changer/add IO modules/add logic control module;
`
`0 add error compensation/replace IO modules;
`
`0 add probing capability/add IO modules/add logic control module;
`
`0 add closed loop scanning probe/add IO modules/replace module;
`
`0 add acoustic emission sensor for tool breakage/add IO module/add logic control module;
`
`0 add real time image recognition of surface finish/add IO add logic control module;
`
`0 add LAN communications functions to support part program upload part program
`download, remote status monitoring and remote data acquisition;
`
`0
`
`0
`
`replace human interface face module with industry de facto standard operator interface;
`
`replace part program interpreter to support CL data generated from AutoCad or
`ProEngineer.
`'
`
`The figure shows seven major systems that make up the components of open architecture
`modular controller. These are the 10 system, control loop system, logic control system, axis
`group, part program interpreter system, human interface system and the task coordinator system.
`Each system is made up 'of one or more replaceable modules. The modules are tied together
`through exposed interfaces. A key concept in modular open architectures is that the system may
`be incrementally adapted to changing requirements. The three mechanisms for adapting the
`system are to add modules, to replace modules and to reconfigure modules by reconnecting the
`interfaces
`
`Page 10 of 53
`Page 10 of 53
`
`

`

`The 10 system consists of one or more IO modules. Each 10 module represents a sensor or
`actuator. The 10 module interfaces are used by control loop modules, axis group modules, logic
`control modules and human interface modules. Sample timing for 10 modules is contro11ed by
`the task coordination module.
`
`The control loop system consists of one or more axis control loop modules. Each axis control
`loop module requires two or more 10 module interfaces. These represent sensor input and
`actuator output. Each axis control loop module provides a command interface that is normally
`connected to an axis group module. Control loop modules may provide additional interfaces that
`allow features such as status information for the human interface, monitoring/tuning of internal
`parameters, real time data collection and real time algorithm modification. Control loop module
`operation is to compute an algorithm to generate a new actuator command based on current
`sensor readings, commanded set points and machine state.
`
`The logic control system consists of one or more logic control modules. The system normally
`contains a large number of logic control modules with a variety of requirements for 10 module
`interfaces. Logic control modules provide an interface to the task coordinator module that allow
`status and event transition information to be conveyed. Logic modules may provide an interface
`that would normally provide status information to the human interface module. Logic control
`modules may also provide an interface to be used by part program interpreter modules. Logic
`control module operation is distinguished from loop module operation by the fact that logic
`control modules execute Boolean equations to generate new 10 output values and detect event
`transitions based on IO inputs and machine state.
`
`The trajectory generation system consists of one or more axis group modules. An axis group
`module requires at least one control loop interface for each coordinated degree of freedom in the
`computed trajectory.
`It may also require additional
`control
`interfaces
`if
`it
`supports
`algorithmically related motions (electronic gearing). An axis group module may also require one
`or more IO module interfaces to provide sensor modified generation such as impedance control.
`An axis group module provides ‘at least two interfaces one of which is normally connected to
`either a task coordinator module or part program interpreter, and the other of which is normally
`connected to the human interface to provide manual jog capabilities.
`
`The part program interpreter system consists of one or more part program interpreter modules. A
`part program interpreter module requires one or more trajectory modules interfaces. A part
`program interpreter may also require one or more logic control A part program interpreter uses
`several system infrastructure services - primarily file system services. A part program interpreter
`provides an interface that is normally connected to a human interface module.
`
`The human interface system consists of one or more human modules. The collection of modules
`in the human interface system will normally require at least three interfaces - an interface to a
`part program interpreter, an interface to an axis group for manual jog capabilities and one or
`more 10 module interfaces for low level interactions such as button activation, feedrate overn'de,
`
`etc. The human interface system may‘also use any interfaces available for system modules to
`supply status information.
`
`Page 11 of 53
`Page 11 of 53
`
`

`

`The task coordinator system normally consists of one task coordinator module. A task
`coordinator module may require a variety of logic control module interfaces to detect event
`transitions and evaluate system state. The task coordinator module operation is to system state '
`and to schedule execution of system modules. A task coordinator may provide an interface
`normally used by the human interface module for machine status information.
`
`Page 12 of 53
`Page 12 of 53
`
`

`

`PART I: GENERAL INFORMATION
`
`1
`
`TECHNOLOGIES ENABLING AGILE MANUFACTURING —— _
`
`INTELLIGENT CLOSED LOOP PROCESSING ——
`
`Part 1: General Information
`
`1 General
`
`1.1 Scope
`
`1 of a series of specifications for
`This part of the TEAM API specification constitutes part
`intelligent closed loop processing and should be read in conjunction with the other parts of the
`series. This TEAM API specification applies to closed loop processing -
`including module
`interface programming; command, control and communication;
`infrastructure and system
`services; and the scaling of functionality based on selected equipment and desired application.
`The purposes of this specification are:
`
`— to establish the definitions and identify the principal components relevant to closed
`loop processing;
`
`-
`
`-
`
`to specify the requirements for scaleable service, infrastructure, and resources;
`
`to define the behavior, communication and input/output as specified by an Application
`Programming Interface (API) for the closed loop processing modules;
`
`-
`
`to give examples and application guidelines to the user.
`
`1.2 Object ofthe Specification
`
`The key objective of defining an API specification is to enable the design and implementation of
`an open, modular control architecture which:
`
`— provides a migration path from the existing practices;
`
`—
`
`-
`
`-—
`
`—
`
`-
`
`—
`
`allows an integrator/end user to add, replace, and reconfigure modules
`
`provides the ability to modify spindle speed and feed rate according to some user
`defined process control strategy
`'
`
`allows access to the real-time data at a predictable rate up to the servo loop rate
`
`allows full 3-D spatial error correction using a user defined correction strategy
`
`decouples user interface software and control software and makes control data
`available for presentation;
`
`provides communication fimctions to integrate the controller with other intelligent
`devices
`
`Page 13 of 53
`Page 13 of 53'
`
`

`

`PART 1: GENERAL INFORMATION
`
`2
`
`— increases the ability of 3rd party software to interoperate with the long-term goal of
`true plug-and-play. For example:
`
`Replace~ a PID Control Law with a more sophisticated Fuzzy Logic Control Law
`
`Collect servo response data with a 3rd party tool, and set tuning parameters in the
`appropriate Control Law Module
`
`Add a force sensor, and modify the feed rate according to a user defined process
`model
`
`Perform high resolution straightness correction on any axis
`
`Replace user-interface with third party package and configure identically to
`existing machine user-interface
`
`1.3 Object of Part]
`
`This part of the TEAM API specification gives the 'following information:
`
`— the rationale and need for an Open Architecture specification;
`
`— the basic requirements of an Open Architecture controller;
`
`-
`
`the definitions and the principal characteristics relevant to a common set of open
`architecture module definitions. The term module will be considered equivalent to the
`notions of primitive and aggregated components and will be defined with class
`definitions.
`
`— the steps in general Life Cycle to build a Open-Architecture controller;
`
`—-
`
`the roles of the major participants;
`
`— the responsibility of the TEAM API working group;
`
`-
`
`some examples to clarify the general API specification model.
`
`1.4 Normative References
`
`ISO/IEC 9506-1 1990, Industrial automation systems - Manufacturing Message Specification
`(MMS) 7 Part 1: Service Definition.
`I
`
`ISO/IEC 9506-2 1990, Industrial automation systems - Manufacturing Message Specification
`(MMS) - Part 2: Protocol Definition.
`
`ISO 10303-41 Industrial Automation Systems and Integration Product Data Representation
`and Exchange - Part ‘41: Integrated Resources: Fundamentals of Product Description and
`Support.
`
`ISO 10303-42 Industrial Automation Systems and Integration Product Data Representation
`and Exchange - Part 42: Integrated Resources: Geometric and Topological Representation.
`
`Page 14 of 53
`Page 14 of 53
`
`

`

`PART 1: GENERAL INFORMATION
`
`3
`
`IEC 1131-3 Programmable controllers - Part 1: General Information, Oct. 1992.
`
`IEC 1131-3 Programmable controllers - Part 3: Programming Languages, March 1993.
`
`(NGC)
`“Next Generation
`for Manufacturing Sciences),
`NCMS (National Center
`Specification for an Open System Architecture Standard (SOSAS), Revision 2.5”, August
`1994.
`
`EIA Standard 441, “Operator Interface Functions of Numerical Controls”, Electronics
`Industries Association, Washington, DC, January 1979 (Reaffirmed July 14, 1992)
`
`EIA Standard - EIA—Z74-D, Interchangeable Variable, Block Data Format for Positioning,
`Contouring, and Contouring/Positioning Numerically Controlled Machines,” Engineering
`Industries Association, Washington, DC, February, 1979
`
`2 Definitions
`
`The TEAM API Workgroup use the following definitions for the following terms. Terms that are
`more specific to closed loop processing are defined in the corresponding parts in order to make
`them self-readable.
`
`Application Programming Interface
`
`The protocol by which one interacts with a module.
`
`Class
`
`An abstract data type and inheritances. For example, the Class SERCOS-Driven Axis
`describes objects in the running machine controller. A 3-axis mill would have three
`instantiations of that class; the 3 objects described by that class.
`
`Configuration '
`
`The specification of a module mapping it from a general solution set into a specific.
`solution. Compare: integration.
`
`Design
`
`A description of a system model in terms of classes and APIs (consisting of member
`function descriptions associated with classes).
`
`Integration
`
`The capability to allow the connection and co‘operation of two or more modules within a
`system. Compare: configuration.
`
`Page 15 of 53
`Page 15 of 53
`
`

`

`PART 1: GENERAL INFORMATION
`
`4
`
`Module
`
`A piece of the system that is sufficiently defined such that it can be replaced by another
`piece, by a third party, with same service through the same interfaces, possible states, and
`conditions of state transitions,
`
`Object
`
`An-instantiation of a class.
`
`Object-Oriented Program
`
`A collection of objects interacting through a
`Programming Interfaces).
`
`set of published APIs (Application
`
`Plug and Play
`
`The ability to replace a TEAM API specified module in a control system with a complying
`version from any supplier and achieve the same or better results.
`
`Proxy Agent
`
`A set of objects that allow the crossing of address-space or communication domain
`boundaries. The class describing a proxy agent uses the API of some other class (for which
`it is a proxy) but provides a transparent mechanism that implements that API while
`crossing a domain boundary.
`
`3 Glossary
`
`Terms already defined1n other standards that are frequently usedin this specification are listed
`in this clause for cemenience and "omp1ehenson.
`
`Component
`
`Adopts the SOSAS concept of a reference architecture consisting of primitive and
`aggregate components. Components are defined as abstract building block elements that
`describe functionality and communication. The application architecture is built from these
`components. Components have the following attributes:
`‘
`
`— responsibility;
`
`— peefito—peer or collaborative relationships;
`
`— behavior (specific functionality encapsulated by the component);
`
`— messages, that is, the complete set of specific instructions necessary for invoking all of
`the behaviors encapsulated by the component;
`
`— Application Program Interface(s) or the interfaces a component uses specifically to
`access services provided by the SOSAS notion of an Open Systems Environment.
`
`Page 16 of 53
`Page 16 of 53
`
`

`

`PART 1: GENERAL INFORMATION
`
`5
`
`TEAM will use the term module to refer to both a primitive and an aggregate component.
`
`4 Development and Integration Life Cycle Model
`
`Openness provides benefits and savings through flexibility and extensibility - but openness alone
`does not achieve interoperability. Application programming interfaces for one vendor’s open
`system will generally not run under another vendor’s system. Openness is but the first step
`towards “plug-and-play” interoperability which in turn is dependent on some form of a standard.
`Requirements for a standard “open solution” include the ability to allow the development of
`controllers by users or system integrators who want
`to piece together their own systems
`component by component, modify the way their controller perform certain actions, apply their
`modifications to another controller, or start small and upgrade as they grow.
`
`Control systems are built as a set of connected components that require assumptions as to the
`scope and operation of interdependent components. The development of a general set of control
`system components assumes that each module can span a broad range of applicability. To build
`an application system from the general component set, configuration of individual modules and
`the integration of modules must be specified, tested and evaluated in the development of “plug-
`and-play” systems. Describing the general API
`for a module is extensive. Additionally,
`describing the services and levels of efforts of dependent resources requires a Life Cycle in order
`to understand the roles and relationships of elemental and aggregate components in the
`developmental process. The TEAM API Workgroup has developed a Life Cycle that divides the
`TEAM API Development and Integration Process into five phases:
`
`1. Module Definition Phase,
`
`2. Module Creation Phase,
`
`3. Module Configgmtion,
`
`4. Module Integration, and
`
`5. System Initialization.
`
`More detailed steps of the TEAM API Development and Integration Process is shown in the
`series of figures 3-7. The TEAM API specification realizes that in addition to the standards-
`developers - such as the TEAM API workgroup - there are other perspectives within the model:
`
`— control component development
`
`- system integrator
`- users
`
`Each perspective will be further reviewed within the Life Cycle.
`
`Page 17 of 53
`Page 17 of 53
`
`

`

`PART 1: GENERAL INFORMATION
`
`6
`
`4.1 Control Component Developers ’ Tasks
`
`Control vendors provide component products and support for hardware or software modules. For
`control vendors to confOrm to an open architecture specification, they' would be required to
`' conform to several specifications including:
`
`— module class specification;
`
`— system service specification;
`
`— customer specifications.
`
`A mechanism similar to the NGC profile is required to describe the system service specification
`that would include such areas as platform capability, control devices, and support software.'The
`system services describe the platform and infrastructure support (such as communication
`mechanisms) and the available resources (disks, extra memory, etc.) Computer boards in turn
`have a device profile that includes CPU type, CPU characteristics and the CPU performance
`characteristics. Included within the profile is the operating system support for the CPU. Sensor-
`effector devices such as controller cards or drives, would subscribe to a general electro-
`mechanical classification and then provide a more detailed capability feature profile.
`
`System Services /
`Custom: Services /-
`
`Standard /
`
`To Figure 6
`Controller
`Services
`ervices Required
`
`from
`
`Other Modules
`““1“!“
`De
`tron
`fini
`
`
`
`
`
`Module Def.
`for
`.One Module
`
`To Figure 6
`
`Figure 3. Life Cycle - Control Component Suppliers Tasks
`
`Page 18 of 53
`Page 18 of 53'
`
`

`

`PART 1: GENERAL INFORMATION
`
`7
`
`4.1.1 Services Re . uired from Other Modules
`
`
`
`Created by:
`Definition:
`
`
`
`
`'
`(Control Component Providers)
`Parameterization and definition of services that are required from other
`_. AA‘JAn
`luvuunvn
`
`Fed into:
`
`D