Many faults caused by interactions, root cause can only
tell that
Two reasons for fault:
Not programmed correctly for condition/situation
Unanticipated fault
Faults may be transitory in nature: hard to detect
Diagnostics should be integrated, not add-on
Interactions
HMI
Open architecture: Allows choose the best components
Modular in nature, need reliable communication
Platform independent, portable
Encapsulation of program, user-friendly interface
Safe systems exist (airplanes), diagnosable systems exist
(automobile engines)
Failure - System should halt in safe state
Ladder logic - Current state not traceable, put program continues
to run (contrast with other programming languages). Note:
current state of the system can
also be traced in ladder logic controllers if programmed
correctly.
Any replacement of ladder logic will be met with resistance if
operators will still have to access low level code
1B: Machine-Builder Needs
What are the current obstacles in writing the logic control for
manufacturing systems? What could improve the systems?
No standard to write control logic
Robustness of (windows) O/S for PC based logic control is a
major concern (note: don't let anybody put other S/W on control computer)
Lack of mechanical specification for developing control logic
(what machines can do and are supposed to do)
No good translators from language based descriptions to logic
based description
Using different programming languages
Too many languages, difficult to master all of them
Different languages work better with different models
Need new discipline that combines Mech - Elec - CS
Platform independent languages like Java: Java is well-suited
for discrete event systems (i.e. it is object-oriented,
platform-independent, interpreted vs.
compiled, and has built-in multithreading)
Are the specifications currently received from end users
sufficient? If not, how can they be improved?
Too much detail rather than functional description of the
software, or in some cases
Not enough definition on structure and modularity
Portability of declarations and definitions between CAD,
controller, operator interface
Open architecture
Lacks a good, concise definition, some are too detailed
Openness clashes with proprietary; resistance from controls
vendors
Question of liability (tends to fall on machine builders)
Wish List
More formal training for logic control design in curricula
Integrated tools for machine mechanical and control and
process design
Exchangeable libraries of typical machine modules/tasks
User friendly interfaces
1C: State of the Art in Industrial Control
Recent advances
Better verification
Internet/Ethernet
PCs on the plant floor (60-80 companies in PC based control)
Open device networks, more modular
Working on gulf between DES and PLC/ladder logic in undergrad
education (what are the skills required?)
Problems
Distributed, coordinated control
Encapsulation (must design so that verification is built in)
Large distributed system has enormously complex model
Discontinuity between the education of implementers and engineers
(EE, Computer, control theory, mechanical) -- See previous presentation!
Integrating control engineer in system development from the beginning
Standards
Different ideas from different industries complicates process of
standardizing
Modularity and distributed control vs. centralized
local closed loop vs. supervisory coordination
Standardize or eliminate the glueware between different control
methods
Will PC based control unify languages (ladder logic, Grafcet,
Instruction list,...)?
Wish list
Verification! Validation
Important no matter what the standard
Compare different representations
Description model, e.g. 1499 maps to Model for use with
verification (must have similar capabilities)
1499 has "unnecessary serializations" -- why not use a concurrent
model?
Develop in a systematic way so that you can verify
Standards for synchronizing signals over TCP/IP (note: this is an
application layer problem)
Ethernet in discrete event control -- application layer
Multidisciplinary education: new standard?
"Programming skills" in control
1D: Collaboration Avenues
Specific projects
Scientific criteria, metrics
Language
Structure
Architechture
Compare different logic control approaches
Interdisciplinary, Integrated
Timespan: short term vs. long term (perceived fear from academics
for working on short term problems?) (note: could also be
fear from academics of working
on complex industry problems that will take too long to solve)
Retraining industry: new teaching methods
(note: academia may also need retraining
to perform research in the current industrial environment)
Resource
Curriculum: both grad and ugrad, disciplinary specific vs.
industrial practice (multidisciplinary), course on system integration --
machine design and control (note: should redesign undergraduate
education to incorproate integrated-design oriented teaching methods
see example)
2A: Finite State Machine Framework
Exciting, promising new developments in FSM for logic control.
Push to move safety control from hardwired implementations to software
implementations.
Matlab stateflow for FSM simulation in coursework.
Integrating UML and FSM validation tools.
Integrating FSM validation tools (e.g. Valid Tool Set) in Microsoft
Visual Studio.
Verification of mission critical / safety function GUI's in medical
applications.
Potential integration of logic control and diagnostics using recent
work in diagnostics of DES using FSM models.
Barriers to implementing research results
Lack of commercially available tools that employ new research results.
Design
Verification
Execution
ex. Siemens higraph
Information is lost between developers of new tools and customers of
those tools.
Small market for new tools, in comparison to tools such as Visual
Studio.
Acceptance by end users of new techniques.
How to overcome these barriers
Systematic method for reducing the risk of changing to new techniques.
Look to other industries, aerospace and railway, to see how it is
managed there.
3rd party neutral evaluation.
2B: Petri Net Framework
Recent developments
Grafcet
SFC
No applications in North America
Applications in Europe (France) and Japan
Flow charts
Some proofs for validating/verifying control code
Barriers
Only applied to automated cycles
PLC dominating companies resisting changes
No one wants a new language
Lack of education
No standard
Lack of communication/understanding between industry and university
Industry relies on vendors for information about logic control
How can these barriers be overcome?
Industry needs to provide a benchmarking test
Form partnership
Standardize
Automate downstream parts of design to increase benefits
Need information/help from industry
Best examples of research implemented in industry
Reusable flowcharts in large applications
Limited use of Petri nets (most Petri-net software programming done
in-house)
The most important problems in using a Petri net framework?
User friendly interface
Perfection of Petri Net description of language
Perfection of control code generation
2C: Emerging Frameworks
Petri nets
Hybrid automata
Distributed
Reconfigurable
Autonomous distributed
Academic/Industry needs
Compositional methods: distributed methods don't always reduce
the complexity accordingly
Modular design
Interfaces/Interlocking
Consider human interaction
Barrier:
Evaluation of current problem
2D: Technology transfer
Barriers
Lack of time to spend with academics
Industry: fully implemented solutions, prototype to final
product
University knowledge of current technology
Not much collaboration between industry and academics. Need a
medium: internet?