Highlights
|
Slides
Execution Systems
- What is a "next generation"
manufacturing execution system?
- What were our goals in the development of such a
system?
- Why were OO methodologies and tools chosen and
how did they contribute to attaining our design
goals?
The Traditional MES(S)
- Poorly integrated
- Monolithic
- Inflexible
- Difficult to change
- Expensive to maintain
What IS a "next
generation" MES?
- A 3-tier client-server architecture based upon a
message-passing object model.
- Reusable software classes or components which
represent a Manufacturing Domain Model.
- Plug & play application modules.
What Were Our Goals?
- Take the time to write down a list
Why Object-Oriented?
- Based upon the SEMATECH SGMM.
- Complexity of the domain model.
- Component/object nature of the architecture.
Factors For Success
- 3-tier client/server.
- Platform independence - common core services.
- Integration with existing tools - standards
compliant.
- Plug & Play, "shrinkwrapped"
components - encourage third-parties to develop
add-ons.
3-Tier Client/Server
Architecture
FACTORYworks Component Framework
Key Foundation Components
- Interprocess and object communication.
- Persistent object storage.
- Deployment language(s).
- Support libraries and/or frameworks.
Implementation - Critical
Factors
- Scalability - need to grow to very many users.
- Availability - resistence to failure.
- Integrity - maintain data validity.
- Consistency - use a common framework API.
- Integration - work with existing equipment and
systems.
Architectural Components
- Distributed Message Bus - DMBX
- Object Repository and Database - RDBMS
- User Presentation Services - GUI
- Distributed Transaction Processing Framework -
DTPF
- Application Component Classes - Transactional API
Distributed Message Bus
Why a message bus and not RPC or Corba?
- Lower network overhead.
- Scales better for many users.
- Corba not available when system was implemented.
- CELLworks required for some components.
CELLworks Message Bus - DMBX
- Proven middleware for client-server manufacturing
systems.
- Application location independence.
- Platform independence.
- Reduced programming requirements.
Object Repository & Database
Why use a relational database as an object
repository?
- Industry standards.
- Better 3rd-party support.
- Maturity and perceived reliability of products.
- More familiar to developers and engineers.
Interfacing C++ Classes To
Relational Database
- Database independence.
- Hybrid O-O/Relational systems.
- Object mapping vs. object wrappers.
- Develop our own interface library.
User Presentation Services - GUI
Mixed platforms require different services.
- Microsoft Windows-NT
- Visual Basic and OLE custom controls
(OCX).
- Simple customization using standard
tools.
- Many engineers are comfortable with VB.
- Unix and X-Windows
- Simple customization using CELLworks
tools.
- Ease of use with standard workstations.
Distributed Transaction
Processing Framework
- Easily understood and used by application class
developers.
- Reduced programming overhead.
- Fully orthogonal & testable (black-box)
behavior.
DTPF - Utility Class Library
General utility and support classes:
- String handling
- Collections - ordered (array), set, dictionary,
binary-tree
- Errors
- Event tracing
- Tokenizer
- International languages
- Garbage collection
DTPF - Distribution Class
Library
Generic object communcations and event management:
- Distribution class registration and metadata
- Object marshaling and unmarshaling
- Callback function and object registration
- Message bus event manager
- Server command and option processing
DTPF - Persistence Class Library
- Abstract interface to object repository.
- Dynamic generation of optimized SQL code for
target DBMS.
- Generation of universally unique object
identifiers.
- Automatic memory management and intelligent
object reference semantics (lazy-fetch via smart
pointers).
- Minimize programmer concern with circular and
recursive object references.
- Manage complex referential integrity issues.
DTPF - Presentation Class Library
- Abstract (message-based) interface to window
system.
- Registration of callback handler functions and
objects attached to window events and widgets.
FACTORYworks Core Class Library
Service Classes:
- Object versioning
- Networks, trees, and lists
- Object caching
- Rule processing
- Domain attributes
- State machines
FACTORYworks Core Class Library
User Interface Classes:
- Error handling
- Acceptance dialogs
- Object editing
- Event notification
Application Component Libraries
Base product libraries and transactional API:
- Site Modeling (MDL)
- Process Planning (PRP)
- Work-in-Process (WIP)
- Equipment Status Monitoring (EQP)
- Operator Tracking (OPR)
- Engineering Data Collection (EDC)
FACTORYworks Execution Model
- Multi-platform work dispatch clients.
- Distributed application servers.
- Custom business rule processing.
Work-Flow And Dispatch
- Clients for Unix and Windows-NT.
- Platform and language independent API.
- Business rules to control work flow.
Unix Run-time Client
NT Run-time Client
Business Rule Processing
- Tailor system behavior to enterprise needs.
- Rule processing can be arbitrarily complex.
- Rules are persistent - stored in the database.
Application Servers
Basic services provided by servers for each
application component library:
- Site modeling - MDLsrv
- Process planning - PRPsrv
- Work-In-Process - WIPsrv
- Operator tracking - OPRsrv
- Equipment status and monitoring - EQPsrv
- Engineering data collection - EDCsrv
Conclusion
- Extensible framework for MES.
- Use familiar tools to build systems.
- Works the way you want it to.
- Not perfect, yet...
|
Presented
September 10, 1996 
Boston, MA 
