0 evaluări0% au considerat acest document util (0 voturi)
168 vizualizări44 pagini
The document discusses issues related to LCU (Logic Control Unit) architecture. It covers parameters for evaluating controllers like size, functionality, performance, communication channels. It also discusses ways to accommodate technological change, requirements for control programming languages, functional capability of software function blocks and examples. Evaluation criteria for function block libraries and process interfacing issues are outlined.
The document discusses issues related to LCU (Logic Control Unit) architecture. It covers parameters for evaluating controllers like size, functionality, performance, communication channels. It also discusses ways to accommodate technological change, requirements for control programming languages, functional capability of software function blocks and examples. Evaluation criteria for function block libraries and process interfacing issues are outlined.
The document discusses issues related to LCU (Logic Control Unit) architecture. It covers parameters for evaluating controllers like size, functionality, performance, communication channels. It also discusses ways to accommodate technological change, requirements for control programming languages, functional capability of software function blocks and examples. Evaluation criteria for function block libraries and process interfacing issues are outlined.
There are endless variations in control structure of LCU
Architectural parameters for evaluating the controllers • Size of the controller-depends on Number of function blocks of number of control statements, number of I/O channels • Functionality of the controller-mix of functional blocks or language statements, mix of process i/o types(analog or digital) • Performance of the controller-rate at which controller scans the I/P and process the variable to generate control signal • Communication channels out of controller-The number, type and speed of the controller to communicate with other devices • Controller output security-manual backup or redundancy Ways of accommodating technological change • Select the hardware that is state of art, but has reached reasonable level of stability • Make sure components are available from more than one vendor • Design or select a DCS whose architecture can accommodate technological change without the need for scraping the system or making major change • The vendor should have prior digital system design experience in the users area of interest. Requirements on control programming language • It must allow the user to specify the control and computing functions to be implemented in a comfortable manner • Able to configure the control strategy instead of programming it. • It must allow the user to implement the existing conventional control alg. • Communication functions are required to exchange information bet. devices LCU Languages Required control and communication functions Major language alternatives Functional capability of software function blocks • Functions are provided that would be very difficult or expensive to implement in hardware. Ex time delay, exponential and matrix fns. • Since fn blocks are implemented in software control configuration can be easily changed • Conversion of physical inputs into engineering units (ex. milliamps into Celsius) Example of a batch reactor Evaluation of Function Block Libraries • Libraries in which blocks are large or small • Function blocks with complex computational functions • Method used to pack the function blocks in LCU It depends on the amount of LCU resources (in memory and computational time) required to implement the block. • Range of control applications that can be implemented with given set of Fn. Blocks. • The number of function blocks offered is not necessarily a valid measure of the quality of the library. • Software design approach used in implementing the function blocks must be consistent with the execution capabilities of the processor and the accuracy requirement of the application. • User must examine the specific mathematical equation Problem oriented Languages • It is a special purpose language, each one tailored to a particular vendors hardware, specific control application • Two popular types • Fill in the form-user fills the form provided by the vendor for his application • Dis. Adv. • The user cannot determine the structure by themselves • The definition procedure is tedious • There is little or no standardization in the forms from one vendor to other • batch language-consists of set of commands that direct the LCU to perform certain operations(Ex. Opening valve) • Its very concise in its implementation of sequential control logic • User must specify the parameters of continuous control functions separately High level languages Major Functional areas to be considered for the evaluation of various language options • Interfacing with the process • Coping with the real time environment – Interrupt handling capability to external events – Ability to schedule multiple application programs or multitasking – Software timers and real time clocks • Interfacing with other elements in a DCS • Providing the security features required in a control application – Error checking and exceptions handling mechanism – Redundant processors – Software must support hardware security features – System software must contain orderly procedures for memory access to avoid scrambling • Supporting the utilities required to write and maintain the programs Process interfacing Issues Functions of communication interfaces • To allow several LCUs to implement control strategies that are larger in scope than possible with a single LCU • To allow transmission of process data to the higher level system elements • To allow these higher level elements to transmit information requests and control commands to the LCUs • To allow two or more LCUs to act together as redundant controllers to perform the same control or computational functions • To augment the I/O capacity of the LCU with that of data input/output units (DI/DOs) in the system Functions of Low level human interfaces • Interfacing hardware directly connected to LCU rather than over the shared communication facilities • Allow plant operator to control the process • Allow the operator to override the automatic equipment and control the process manually in case of a controller hardware failure • Allow the plant instrumentation engineer to configure the control system logic and later tune the control system parameters Security design issues for LCU Security Objectives • Make sure that the failure of a single control system element does not shut down all automatic control functions • If failure of a control system causes loss of automatic control in a portion of the system, make sure that there is a mechanism that allows the operator to take over manual control of that portion of the process • Ensure that the control outputs are safe one Three Security design approaches • Provide manual backup only Designed to implement only one or two control loops Provide a standby redundant controller • Control output is fed back to both controllers to allow bumpless transfer to be accomplished Provide multiple active controllers • In this approach failure of one controller doesn’t affect the automatic control function Techniques to improve the security of the control output circuitry Implementation of different techniques for secure control output Major design principle of Manual Backup Manual Backup Configurations Guidelines to design redundant controller Approaches to design redundant LCU Architecture