Lecture Building reliable component-based systems - Chapter 17: Architectural support for reuse. In this chapter, the following content will be discussed: Industrial automation systems, the motivation for a platform, the architecture, developing a domain specific application.
Chapter 17 Architectural Support for Reuse Building Reliable Componentbased Overview Industrial Automation Systems The Motivation for a Platform The Architecture Developing a Domain Specific Application Building Reliable Componentbased Industrial Automation Systems Highly specialized, independent, and incompatible hardware and software system solutions A flexible combination of basic hardware and software components, communications infrastructure, and application components Building Reliable Componentbased The 6-layer Model of a Technical Process Enterprise Level Production Management Level Process Control Level Group Control Level Field Level Process Level Building Reliable Componentbased The Motivation for a Platform Envisioned seamless link between front-end business processes and plant control processes: Motivations for a large global company to invest into the development of a “single” platform Avoidance of parallel developments in different business segments Harmonization of the diversity of ‘legacy’ automation platforms acquired through company mergers or resulting from previous parallel developments Adoption of product line business strategies (i.e pursuing a system family concept both within and across vertical market segments) Implicit expectation of a reuse payoff Building Reliable Componentbased The Architecture AspectObject, Object Type, Aspect and Aspect Type Aspect System A collection of Aspect Types for a certain context or purpose Domain-related reuse AspectSystemObject Some Aspect-specific software is needed (binary) Software component; Microsoft COM component following specific rules The basic set of ASOs distributed with the AIP contains functionality for alarming, event handling etc Building Reliable Componentbased AspectObjects The most central type of entity in the model AspectObjects model physical objects E.g a specific valve in a dairy (“FIC 201 Valve”) Does not contain any data Related data is carried by its Aspects Aspect Aspect Aspect AspectObject Aspect Building Reliable Componentbased Aspect Encapsulates a subset of the data related to an AspectObject Different types of electronic information (e.g documents) Valve Valve 1 1 Control Operator Graphics Operation Report Mechanical Drawing Building Reliable Componentbased Maintenance Instructions Aspect Types Defines how the data in an Aspect is used In a “Mechanical Drawing” Aspect, the data is opened with AutoCad In a “Maintenance Instructions” Aspect, the data is opened with Acrobat Reader Reuse! Aspect Type +Name : string(idl) = "Mechanical Drawing" +Action : string(idl) = "Open With AutoCad" Aspect +Data : = 10110100010110010110 Building Reliable Componentbased Aspect Types, cont Aspect Type +Name : string(idl) = "Mechanical Drawing" +Action : string(idl) = "Open With AutoCad" Aspect +Data : = 10110100010110010110 Building Reliable Componentbased Object Types Models the type of an AspectObject The type of “FIC 201” is “Valve” Defines what Aspect Types an AspectObject can have A “Valve” can have a “Mechanical drawing” etc Reuse! Building Reliable Componentbased Object Types, cont Object Type +Name : string(idl) = "Valve" +Aspects : Aspect Type = "Mechanical Drawing", AspectObject +Name : string(idl) = "FIC 201" +Aspects : Aspect Building Reliable Componentbased Structures Models a structure Location structure Functional structure Batch structure Typically, each AspectObject is part of several structures Building Reliable Componentbased Structures, cont Building Reliable Componentbased Structures, cont Location structure Enables browsing through the physical layout See what valves are physically connected to a pipe Functional structure Enables browsing through the functional layout See what control units are connected to a valve Building Reliable Componentbased Physical view Client-server system Freedom to choose number of servers Scalability Reliability Freedom to choose number of services Building Reliable Componentbased Physical view, cont WP host WP SH A SH C SH A SH B Service group A WP host WP Service group B SH C Service group C1 Service group C2 SH B station network Server/WP host WP ASM SH A Server host SP C SH B ASM SP A SP B Server host ASM SP C SH C SP A Server host ASM SP C SP: service provider ASM: Afw Service Manager Controller Controller Controller WP: workplace Building Reliable Componentbased SP B SP C Controller network SH: service handler SP A Controller Developing a Domain Specific Application Jacobson et al have introduced the distinction between an application system and a component system: Reusing a single component is usually insufficient Requires the reuse of a set of components A set of components must be reused to obtain the alarm handling functionality Building Reliable Componentbased 4-Layer Representation Application system layer: Offers a coherent set of use cases to some end users The business-specific: Layer several component systems used by the application engineer The middleware layer: Independent of particular types of business GUI builders, database management systems, etc The system software layer: Operating systems Indistinct boundaries between itself and middleware Building Reliable Componentbased AIP Reuse Hierarchy enablers project specific templates and patterns domain specific templates and patterns AIP built-in admin Object Types AIP built-in admin Aspect Types AIP built-in generalpurpose Object Types domain specific Object Types AIP built-in generalpurpose Aspect Types domain specific Aspect Types project specific Object Types AIP export/import project specific Aspect Types project specific ASOs AIP base ASOs OT inheritance AIP export/import AT inheritance project specific Services AIP base Services engineering guidelines and tools AIP library concept 3rd party applications AIP base infrastructure W2k Building Reliable Componentbased COM VC++ configuration Some Words of Caution Possible risks: Only relying on a platform, not having a reuse-driven process or product line practice with a top-down and planned approach to reuse will not succeed Requirements management: Requirements elicitation, prioritisation and trade-offs across products, domains, and organizational units are extremely complex Bugs in a released version Building Reliable Componentbased ... Industrial Automation Systems The Motivation for a Platform The Architecture Developing a Domain Specific Application Building Reliable Componentbased Industrial Automation Systems Highly specialized,... Process Level Building Reliable Componentbased The Motivation for a Platform Envisioned seamless link between front-end business processes and plant control processes: Motivations for a large global... a valve Building Reliable Componentbased Physical view Client-server system Freedom to choose number of servers Scalability Reliability Freedom to choose number of services Building Reliable Componentbased