Requirements

Introduction

Model based controls system development starts from product requirements. The highest level and most abstract product requirements originate from the customer needs and the marketing analysis. The organized and analyzed customer needs are translated into the technical system requirements through applying functional analysis to start the product development: what functions the product needs to provide to meet the customer and market needs. The customer and market needs to be satisfied by the product are chosen on the other side based on the company’s resource, product development cycle, product line development plan, and marketing strategies.

After the system level requirements are decided, the control subsystem level requirements need to be defined to begin the control system development. For embedded control systems, which is focused in this book, the overall control functions are implemented in software running on a hardware computing platform within the product, the controls software, as part of the overall product application software which also includes other software modules such as graphical user interface, and network communications, etc. So control subsystem requirements are in effect the requirements on the controls software.

Requirement flow down first starts from the system level to the subsystem level. From the product structure perspective, the controls subsystem is comprised of all elements (hardware, software and firmware) involved in providing and supporting the dynamic behaviors and functions of a product defined by the system level requirements. For example for a vapor compression cycle air conditioning system, the control subsystem includes the compressor, evaporator, condenser, indoor and outdoor fans, measurement sensors such as pressure and temperature sensors, controller board and the embedded controls software. In general, the control system hardware includes the physical system under control (called the plant in controls term), actuation and sensing devices. In the air conditioning example, the plant is the assembly of the compressor, evaporator, condenser and pipes connecting them; assume the evaporator is equipped with a thermal expansion valve for superheat control at the compressor inlet and the compressor is controlled by a variable frequency speed drive, then the compressor variable frequency speed drive is the actuator which regulates the compressor speed; if fan speeds are adjustable instead of being fixed, then the various fan drives are actuators for changing the fan speeds too; pressure and temperature sensors installed at various locations in the system are the sensing devices for measuring controlled variables, for example the supply air temperature, and for monitoring internal variables for safe operation, for example the compressor suction superheat to prevent compressor from flooding. Based on the product structure design, the control subsystem components are identified along with its dynamic behaviors and interdependencies. The control subsystem requirements are collected, derived and then separated from the product system requirements, which describe the controlled system behaviors and performance for intended use cases. At this point, the interfaces between the control software and the rest of the application software needs to be thoughtfully defined based on the overall software application structure, for example the way in which the data is managed and shared among different modules of the application software.