C
Open Modular Architecture Controller

INTRODUCTION

The following section reviews two key operations within the TIME program. The Melt Pour and Twin Screw Programs provide unique challenges to the TIME Infrastructure. Each program’s operation and control scenarios are examined in detail to determine their overall control requirements. These operations demonstrate the demanding control requirements of the TIME project.

MELT POUR OPERATION

Overview

The Melt Pour Operation, as the name suggests, involves the melting and pouring of High Energy Material (TNT) into projectiles. We will examine the basic operation of the Melt Pour Operation looking for control points and requirements. The goal of the following examination will be to identify the control scenarios needed to create an automated Melt Pour Operation. As seen in the diagram below the Melt Pour Operation Consists of the following components:

  • Projectile Component Pre-Heaters—Brings Projectile Components to Proper Temperature

  • Melt Kettle—Prepares TNT Material

  • Pour Machine—Dispenses TNT Material

  • Cooling Bay—Controls Cool Down of Filled Projectile

  • Probe Machine—Inspects TNT Material for Desired Temperature Profile



The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement



Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 158
Munitions Manufacturing: A Call for Modernization C Open Modular Architecture Controller INTRODUCTION The following section reviews two key operations within the TIME program. The Melt Pour and Twin Screw Programs provide unique challenges to the TIME Infrastructure. Each program’s operation and control scenarios are examined in detail to determine their overall control requirements. These operations demonstrate the demanding control requirements of the TIME project. MELT POUR OPERATION Overview The Melt Pour Operation, as the name suggests, involves the melting and pouring of High Energy Material (TNT) into projectiles. We will examine the basic operation of the Melt Pour Operation looking for control points and requirements. The goal of the following examination will be to identify the control scenarios needed to create an automated Melt Pour Operation. As seen in the diagram below the Melt Pour Operation Consists of the following components: Projectile Component Pre-Heaters—Brings Projectile Components to Proper Temperature Melt Kettle—Prepares TNT Material Pour Machine—Dispenses TNT Material Cooling Bay—Controls Cool Down of Filled Projectile Probe Machine—Inspects TNT Material for Desired Temperature Profile

OCR for page 158
Munitions Manufacturing: A Call for Modernization Figure C-1 Melt-pour operation The following examination includes additional components that are not seen in the existing diagrams but are necessary to achieve an automated Melt Pour Operation. These additional components are: Integrating Controller—OMAC System Controller Integrated Projectile Handling System—Moves Projectiles between Identified Components. Each of these Components and their operation scenarios is examined below. OPERATIONAL SCENARIOS Projectile Component Pre-Heat The first part of the operation involves heating the projectiles and funnels to the determined temperature. The Funnel and Projectile Preheat Ovens bring the funnels and projectiles to a desired temperature. The OMAC Controller would be responsible for controlling each of these ovens against a model of temperature profiles. The controller must be capable of responding to external commands determining the actual profile of the projectile temperature. The projectile and funnel pre-heat ovens are seen below.

OCR for page 158
Munitions Manufacturing: A Call for Modernization Figure C-2 Funnel and projectile preheat oven The complexity of this control problem is seen in the automated scenario of an integrated projectile handling and delivery system. The OMAC Controller must determine the proper exit temperature from the Pre-Heaters for each projectile component given the following factors: Temperature Loss Model of each Projectile Component Temperature and Humidity in Facility Time Delay Based on Process times for Projectiles ahead of current components. While the Pre-Heaters do not need to perform these calculations it is the responsibility of the Pre-Heaters to respond to the temperature profiles based on these calculations. Melt Kettle The melting portion of the operation involves combining two forms of TNT. A solid TNT known as Feather Rice is added to molten TNT known as heal. This process of introducing the solid to molten TNT is known as seeding. The exact composition and control of all the materials within this process greatly influences the overall effectiveness of the projectile. A metal grid is used to melt the TNT to form the molten heal. The OMAC controller will have to close loop control the temperature of the grid. The Kettle is agitated to maintain the mixture. Several operational problems result when delivery of the feather is not precise. For example, the agitator can bind if more that 40% feather is added. This creates a critical situation where the high-energy material is stuck in process. This operation problem illustrates the need for precise feed and agitation control.

OCR for page 158
Munitions Manufacturing: A Call for Modernization Figure C-3 Melt kettle The Feather is introduced into the heal through controlled vibratory feeders. The feeders employ constant amplitude vibration with duty cycle to precisely deliver material. The OMAC controller will control the agitators and vibratory feeders to maintain the precise mixture as required. The TIME program is investigating sensor technologies that can provide information on the exact mixture in the Kettle. This information can then be utilized to close the loop on the seeding and agitation operations. The overall mixture within the kettle will effect the vibration and agitation times for the Kettle control station. Pour Machine The Pour Machine consists of a TNT delivery mechanism to 15 projectiles. The current system utilizes pneumatically controlled valves that servo against the total kettle weight to determine material flow. A flow sensor will be included in the automated process allowing for precise real-time control over the pneumatic valve and directly over the material flow rate. The OMAC controller will use the sensor information to precisely contorl material flow to each projectile. The current pour mechanism can be seen in the figure below.

OCR for page 158
Munitions Manufacturing: A Call for Modernization Figure C-4 Pour mechanism Cooling Bay The cooling bay allows for the controlled cooling of the filled projectiles. A heat exchanger is utilized to ensure the exact cooling rates desired by the process model are achieved. The current cooling bay configuration is seen below. Figure C-5 Cooling bay

OCR for page 158
Munitions Manufacturing: A Call for Modernization The OMAC controller will monitor the projectile temperatures and modulate the heat exchanged to precisely control the overall cooling process. The model for the cooling will account for the following factors: Exit temperatures from Pour Machine Material transit time from Pour Machine to Cooling Bay Facility temperature and humidity Desired cooling profile for projectile type In process material ahead of the projectile buggy Heat exchanger characteristics and performance All of these requirements are combined to produce the cooling profile and the inputs to the cooling bay control. As with other models within the melt-pour operation the computation will not be within the facility. The models require tremendous processing power and it will be necessary to run these computations offsite. Several parameters within the model are dynamic and will require constant closed loop monitoring. Probe Machine The final station of the Melt-Pour operation is a probing station that determines the projectile temperatures at designated points within the projectile. These temperatures are used to determine the anticipated effectiveness of the projectile. The goal of the automated system will be to utilize these measurements to help improve the upstream process. The temperatures can be used to control several upstream parameters: Pre-Heat Oven Temperature Melt Kettle Temperature Cooling Bay Profile The OMAC controller’s ability to provide an integrated system allows for the closing of control loops throughout the Melt-Pour System. Integrated Projectile Handling System The automation scenarios of the Melt-Pour operations are contingent on having an integrated projectile handling system. Various material handling systems are available throughout the industry. The Melt-Pour operation relies heavily on precise temperature controls in both heating and cooling of all materials involved. The delivery times associated with moving from one component to another require a deterministic mechanism to move the High Energy Material and projectiles from one station to another. Fine temperature control is lost if the transit time between stations is not deterministic. An automated material handling system will provide feedback to the process models that are determining heat-up and cool-down profiles. The projectile handling must be capable of integrating between various facilities. The material must be

OCR for page 158
Munitions Manufacturing: A Call for Modernization tracked within a single system. The current delivery times from the Projectile Handling System will be used as feedback to the process models to maintain the overall system performance. TWIN SCREW OPERATION Overview The twin screw operation involves mixing of various forms of energetic material along with solvent to form various propellants. Extrusion by definition is the process of compacting and melting material and forcing it through an orifice in a continuous fashion. We will examine the basic operation of the twin screw looking for control points and requirements for both the controller and model. The autonomous twin screw operation requires a very tight integration between the control system and a full model of the extrusion process. The goal of the following examination will be to identify the control scenarios needed to create an autonomous twin screw operation. As seen in the diagram below the twin screw operation consists of the following components: Material Feed Area—solid powder and solvent Extruder Barrel—actual mixing area Die Area—exit area for mixed material Takeaway area—conveyor belt and indexing table area Figure C-6 Twin screw operation

OCR for page 158
Munitions Manufacturing: A Call for Modernization The following examination requires an integrated control system to achieve an automated twin screw operation. Each of these components and their operation scenarios are examined below. Operational Scenarios Material Feed The first part of the operation involves introducing the energetic material and solvent into the extruder. The energetic material is in a powdered form. The powder and solvent are introduced in mix zone 1 and zone 2 as seen below. The facility consists of three solid loss-in-weight feeders, one liquid loss-in-weight feeder for lacquer and one liquid loss-in-weight feeder for the solvent. Figure C-7 Twin-screw extruder for energetics processing The solid material is introduced by utilizing a single screw feed. A loss-in-weight controller is verifies the proper amount of material flow. External agitators ensure proper product feed. The OMAC controller is required to perform the motion control over the screw axis as well as the agitators. The agitators are controller by constant amplitude vibrations under various duty cycles. This technique resembles a PWM controller. High-speed control over the duty cycle is required.

OCR for page 158
Munitions Manufacturing: A Call for Modernization The solvent is feed with a zenith gear control system into two injection ports. The solvent is introduced to zone 2. The entire process model will dictate high-speed flow rate changes both the solid and solvent materials. The OMAC controller will have to provide controller response to these new set points. Extruder Once the material is in the extruder, temperature and pressures are maintained to guarantee product consistency. The Vacuum section of the extruder is responsible for allowing the removal of appropriate amounts of solvent to ensure the desired product characteristics. Temperatures are controlled with four zone heating control. Five surface temperature, water temperature and pressure taps are used to provide control feedback. Die and Takeaway Area At the discharge port of the extruder is a die that is designed to form a cylindrical product. There are separate hot and cold temperature controls for the die area. The takeaway belt from the die area must work to slightly pull the material from the die. Conveyor speeds too high will result in product tearing. Vision systems will be investigated to identify torn product sections that cannot be used. The actual conveyor speeds will by set by the process model accounting for the exit pressure from the die and the material characteristics of the propellant. CONTROL REQUIREMENTS The following tables summarize the control requirements for the Melt-Pour and Twin Screw Operations as well as the entire TIME Program. They provide a requirements list in evaluating the ability of a particular controller to meet the TIME programs needs.

OCR for page 158
Munitions Manufacturing: A Call for Modernization Melt-Pour Program Table C-1. Melt Pour Program Control Requirements (McWilliams 2000a) Component Control Domain Description Pre-Heat Ovens Dual Oven Control Capability Closed Loop Temperature Control Oven Temperature Model Controls Two Commercial Ovens Actual Set Points are determined by process Model Model Parameters • Temperature Loss Model for Each Component • Material Delivery Time • In-process Delays based on material upstream Melt Kettle Closed Loop Temperature Control Closed Loop Single Axis Motion Control Closed Loop Vibrator Control Melt Process Model Controls Metal Grid to a profile as dictated by process model. Agitator Control—Speed set by process model. High Speed time based control over vibrator on/off times to achieve flow rate as dictated by the process model. Model Parameters • Desired Projectile Characteristics • Vibrator Performance • Feather Flow Rate Sensor • Grid Temperature Sensor Pour Machine Closed Loop Pneumatic Valve Control Pour Process Model Servo against flow sensor. Model Parameters • Desired Projectile Characteristics • Valve Performance • Material Flow Rate Sensor Cooling Bay Closed Loop Temperature Control Cooling Bay Process Model Servo against internal temperature sensors. Model Parameters • Exit Temperature from Pour • Material Transfer Time • Facility Temperature and

OCR for page 158
Munitions Manufacturing: A Call for Modernization     Humidity • Desire Profile for Projectile • In-Process Material ahead of Buggy • Heat Exchanger Performance Probe Machine Interface to Probe Data Interface to Probe Data for Model and Statistics. Projectile Handling System Integrated Material Handling Control Physically Distributed Full Material Tracking Material Handling Must work from System Controller and respond to supervisory control. Components are not collocated. Delivery times must be tracked and reported in real-time. Communications Infrastructure High Speed Communications System Wide Data Access Physically Distributed Models must be able to be calculated and return results in milliseconds. All components of the control system will produce and consume information from the models. Models will be run offsite to meet program goals. Pre-Heat Ovens and Melt-Pour are in different buildings with Integrated Material Handling. Twin Screw Program Table C-2. Twin-Screw Program Control Requirements (McWilliams 2000b) Component Control Domain Description Material Feed Motion Control Closed Loop Pneumatic Valve Control Closed loop Agitator Control Single axis control over solid feeders. Servo against flow sensor. Actual Set Points are determined by process Model Extruder Closed Loop Temperature Control Model set points must be maintained in the 4 heating zones in the extruder barrel.

OCR for page 158
Munitions Manufacturing: A Call for Modernization   Motion Control Single Axis control over the extruder speed. Process model dictates the desired extruder speeds. Die and Takeaway Area Closed Loop Temperature Control Single axis motion control Closed loop temperature control over the hot and cold zones of the die area. The process model dictates that temperature set points. Process Model Complex Model is inprocess component to the OMAC Controller. Model Parameters: • Extruder, Barrel and Die Configurations • Material Feed and Speed • Propellant Usage • Temperature and Pressure Sensors • In-Process Material ahead of Buggy • Heat Exchanger Performance Communications Infrastructure High Speed Communications System Wide Data Access Physically Distributed Models must be able to be calculated and return results in 100s of milli-seconds. All components of the control system will produce and consume information from the models. Models will be run offsite to meet program goals. Pre-Heat Ovens and Melt-Pour are in different buildings with Integrated Material Handling. TIME Project Controller Requirements Summary The TIME Projects as discussed in the previous two sections provide a requirements list to potential control products. The heavy reliance on models to close the loops throughout the architecture require each point within the control architecture to be able to produce performance data and respond to new control commands based on the model results. The timings throughout the system require the interactions with the model happen over deterministic, high-speed communications channels.

OCR for page 158
Munitions Manufacturing: A Call for Modernization The TIME programs infrastructure requires that the models often be run at locations other than the production facility. The overall control system for either the Melt-Pour or the Twin Screw Programs will require a flexibility and complexity rarely found in controller implementations. The complexity, consequence of risk and tight integration required between all levels of the controller architecture, reach that of a fighter aircraft. These types of controls systems are characterized by: Closely controlled proprietary architectures Large portions developed in assembly language specific to proprietary hardware Black Box systems where “Open” is not required (and perhaps not desirable) Modifications require large Development Programs Ongoing Support Programs are required for the life of the product (to maintain expertise, provide enhancements, correct operational ‘issues’ and ‘bugs’, provide spare parts and hardware upgrades, etc.) However, these characteristics do not satisfy the requirements of the TIME program. The TIME program requires a true “Open” controls architecture that allows for creation of control loops not originally predicted by the controls developer because of lack of technology or models. As summarized in the preceding tables, the following major features characterize the TIME controller: Model Based Control Closed Loops throughout the Controls Architecture High Speed Deterministic Communications between Facilities Hard Real-Time Capability (Guaranteed Maximum Response Time) Single Paradigm for Models, PLC and Motion Expression Success Dependent on Extensibility and Portability This requirements combination creates two additional major requirements: Need for a Single Development Environment Portability of Logic Need for a Single Development Environment The ability of the TIME Program controllers to be extended will be directly dependent on their approachability. The expression of the control logic and the ability to easily document the control architecture will determine the extensibility of the TIME controllers. These two TIME programs tightly mix PLC, Complex Motion and Process Models. This tight integration must be reflected in the development of the control system.

OCR for page 158
Munitions Manufacturing: A Call for Modernization A controls engineer must be able to work within a single environment which focuses\their train of thought on the development of the control system and not how to integrate different subsystems and languages. The developer must not be constrained by having to move from one environment to another because they needed to touch an I/O bit during a motion loop. Having to move from one package for models and then another for sensor interfacing is not acceptable. This shifting of paradigms from one environment to another causes constraints on the controls system that will stifle the controls engineer’s ability to close loops and create a tighter integration. The controls engineer needs to concentrate on the production tasks and have an environment that supports free flow expression of this logic. The ability to extend the control system will determine its eventual life span. An open, extensible control system, contained in a single development environment must be a stated goal for the TIME program. This requirement will serve as a major discriminator for controls candidates. Portability of Logic A key goal for the TIME program is to be able to leverage commercial installations to increase the overall production capability in times of need. This seemingly simple goal proves to place heavy requirements on control system candidates. The complexity and integration of the TIME program requires a control system architecture that supports all of the “Openness” of the Army’s facilities. The only way to ensure that the commercial site is able to deliver the needed product will be to have the controls logic moved to the commercial location. This true “Portability” requires an electronic standard to be used for the expression of the controls logic. The TIME project cannot afford to recreate the entire control system for each production site. There exists no validation capability to ensure that the logic expressed in one controls paradigm matches that of another. The development of the control system would be constrained by a “Least Common Denominator” of the logic expression at all commercial sites. STATE OF COMMERCIAL CONTROLLERS In light of the TIME program controller requirements, a review of the current state of commercial controllers is required. The cost effectiveness of COTS integration technologies has lead to major innovations within the controls community. Industries characterized by their slow response and long product cycle times are now being forced to reach desktop type one-year product cycles. This demand for product features and marketing pressures has led to the heavy use of undefined terms within the controls community. The use of the word “Openness” has nearly led it to have no meaning. The challenges of the TIME program provide a substantial set of requirements that help focus in on the definition of “Open.”

OCR for page 158
Munitions Manufacturing: A Call for Modernization Model based control Closed loops throughout the controls architecture High speed deterministic communications between facilities Single Paradigm for models, PLC and motion expression Hard real-time support Success dependent on extensibility and portability Commercially available products from companies like Siemens, Modicon and Rockwell are characterized by several basic similarities: Division of PLC logic and complex motion Difficult integration between vendors DCOM as an integration standard Each of these characteristics is detailed below. Division of PLC and Complex Motion The division of PLC and Complex Motion has led to motion capabilities being characterized by strict parameter adjustment to preprogrammed control laws. There exist several products, like the Rockwell Control Logic, which do allow for the introduction of Motion Function Blocks into the PLC logic. The Motion capabilities of these blocks have the following capability: Electronic gearing Master-slave following Pre-programmed profile following With each of these modes there are several parameters for the adjustment of maximum accelerations and velocities. The control laws governing these capabilities are fixed and are not accessible. It is not possible to directly control the gains or modify the feedback loops. For complex motion capability the vendors provide separate packages. These packages offer more complex parameter and gain adjustment. The packages provide several preprogrammed control laws like torque mode and velocity control. The motion products do not allow for actual control law substitution. These separate PLC and complex motion packages require the controls engineer to use different development environments depending on the control problem. Lack of Integration Between Vendors IEC-61131 has provided standard requirements for the expression of control logic. There are five basic expressions of logic, which include Ladder,

OCR for page 158
Munitions Manufacturing: A Call for Modernization Structured Text, Function Block, Instruction List, Sequential Function Charts and others. These standards present the appearance of interoperability of various vendors’ products. The PLC Open committee is enhancing and certifying vendors against different levels of the IEC1131 standard. The definition of being IEC-61131 compliant under PLC Open’s definition requires that a particular product meet 80% of the requirements to achieve certification. This allows for tremendous variation within vendors products. The greatest change of portability between the various companies is in Structured Text expression of logic. Structured Text is a formal language defined by IEC that expresses the logic of a controls solution. The 80% requirement of PLC Open has allowed for various parts of the Structured Text language to be supported by a particular vendor and not on others. To implement truly portable logic, the least common denominator between all candidate control product’s implementations of structure text must be used. This severely constrains the controls solutions. Structured text does not include the required support for complex math based motion algorithms. The structured text can call into preprogrammed function blocks as seen in the simple motion algorithms as described previously. The IEC-61131 effort has tried to create a standard enabling portability between PLC vendors, but because of the allowance of partial compliance true portability has not been met. There are no like efforts for the Motion Control Industry. DCOM Sets Integration standard DCOM has emerged as the Defacto standard for communications integration between controller components. DCOM must be examined against the constraints of the TIME program controllers. DCOM was designed for the desktop world. Real-time to the desktop world is seen in terms of seconds. DCOM is built on top of COM, binary interface standard for Component Encapsulation. DCOM has been heavily leveraged by the HMI world to provide easy integration to commercial controllers. The OPC effort within the controls community has shown the power of the DCOM technology when applied to realistic control problems. The actual implementation of DCOM still provides several challenges to the controls engineer: Difficult Domain-to-Domain Integration Possible large packet delivery latencies Large timeouts on packet failure Each of these areas is examined below.

OCR for page 158
Munitions Manufacturing: A Call for Modernization Difficult Domain-to-Domain Integration DCOM requires that a user meet all security requirements on the server machine before they can access a particular server. This means the user must have an identical account with identical privileges on the client and server machines. This model works well within a particular network domain but is difficult to configure across domains. The normal solution is to configure the user as an administrator across both machines, which violates all security policies in place to protect the system. This configuration is difficult within a single company’s product let alone between two different vendors. Domain-to-Domain DCOM integration difficulties have prevented true enterprise wide integration of control information. Possible Large Packet Delivery Latencies DCOM communications transmit on the normal IT infrastructure Ethernet. The loading of the corporate network is highly unpredictable. DCOM ‘s use in real-time situations requires deterministic bounded response, which is impossible to guarantee with unknown additional traffic. There are technologies, such as high-speed switches, that help to alleviate this problem but they do not solve the problem throughout an enterprise which may span the globe. Large Timeouts on Packet Failure DCOM was built on top of OLE technologies from Microsoft. One of the basic legacy issues with DCOM is the several minute timeout of a packet failure. A client or server is not notified of a delivery failure for up to 6 minutes. This characteristic has been identified as a major impediment for DCOM adoption into critical roles. The DCOM standard has led to major revolutions within the HMI and SCADA industries. However, DCOM’s reach into the real-time world is limited by its configuration, latencies and large timeouts. COMMERCIAL CONTROLLER SHORTFALLS The market has latched onto the “Open” buzz word and uses it throughout their literature. The lack of a true definition for open has lead to major confusion. A quick market study without an in-depth technical analysis of the motion solutions can lead to a false sense that the market is full of “Open” control products. The TIME project offers a very challenging view of the word “Open” characterized by: Support for Model based control Ability to close loops throughout the controls architecture High speed deterministic communications between facilities

OCR for page 158
Munitions Manufacturing: A Call for Modernization Single paradigm for models, PLC and motion expression Success dependent on extensibility and portability Hard real-time support The commercial controllers fall short in trying to meet each one of the TIME challenges: Table C-3 TIME Requirements and Shortfalls TIME Requirement Commercial controllers shortfall Support for Model Based Control Model Based Controls are constrained by the limitations of the development language. Structured Text has only rudimentary math capabilities limiting the complexity of the model and requiring the model to run on the controller. Closed Loops throughout the Controller PLC & Motion TIME’s definition of closing loops is not constrained to a single control discipline. No commercial controllers allow for closing loops to levels that include changing control laws and interacting with the entire control architecture. High Speed Inter-Facility Deterministic Communications DCOM is heavily utilized as communications infrastructure and does not meet real-time deterministic requirements because of latency and timeout constraints. Single Development Paradigm for Models, PLC and Motion Logic Market is led by Simple Motion and Modeling extensions to PLC products. No Product provides the combination of complex modeling and motion along with PLC activities. Most vendors require separate products for each area. Extensibility and Portability Attempts at a portability standard from PLC Open will always fall short because of acceptance of partial compliance. Extensibility is limited with the single control product (PLC, Motion) and does not allow for product growth between these areas. Hard Real-Time Support Most major PC based Control products do not currently support Hard Real-Time across PLC, Motion and Modeling.

OCR for page 158
Munitions Manufacturing: A Call for Modernization The “Open” solution from the OMAC team allows for a unique solution to meet all of the TIME requirements. It allows controls providers to modify the basic behavior of the controller to fit their methodology. Table C-4 TIME Requirements and OMAC Features TIME Requirement OMAC Feature Support for Model Based Control Introduction of Model Algorithms are allowed throughout the controller independent of whether it involves axis position, I/O or calculated variables. Closed Loops throughout the Controller PLC & Motion OMAC allows for access to all variables within the control system independent of type. Data is not classified as being motion, PLC or model data. Control Algorithms have open access to all data within the control system. High Speed Inter-Facility Deterministic Communications The TIME project has lead the way in developing high speed T1 communications specializing in Remote site connectivity. Single Development Paradigm for Models, PLC and Motion Logic The OMAC development environment provides a single location for the expression of all logic independent of whether it is PLC, Motion or Model. The class definitions for all layers of the control system are immediately available to the controls developer without switching tools. Extensibility and Portability The JAVA expression of the OMAC controller provides an industry standard mechanism for the control logic of all aspects of the control to move from location to location. The single development environment allows for the extensibility of all aspects of the control system without respect to it being a PLC, motion or modeling problem. The development concentrates on the control problem and does not have an arbitrary partitioning. Hard Real-Time Support The OMAC controller is built on top of VenturCom’s RTX environment. The RTX environment is recognized by Microsoft and the Controls Industry as the leading Hard Real-Time extension to Microsoft’s Windows NT environment.

OCR for page 158
Munitions Manufacturing: A Call for Modernization The OMAC controller provides a unique solution to the controls requirements of the TIME project. The OMAC controller has been designed with the entire lifecycle needs of the controls engineer in mind, without the legacy constraints that hinder a majority of the control industry’s products. The engineers and designers of control systems are provided with a single development environment that supports a “train of thought” development effort. The engineer does not have to worry about whether the algorithm necessary for the control activity needs data from a PLC or motion system. The engineer concentrates on the problem and the OMAC environment makes sure they have access to all data necessary to solve the problem. In short, the OMAC environment allows the controls engineer to concentrate on the controls problems and not the problems of the development environment.