An ontology-based approach for the instrumentation, control and automation infrastructure of a WWTP

Please download to get full document.

View again

of 7
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Information Report



Views: 6 | Pages: 7

Extension: PDF | Download: 0

Related documents
The instrumentation, control and automation of wastewater treatment plants (WWTPs) is a key aspect to ensure good performance and lower operational costs. However, control systems are seldom interoperable and standard-compliant. In this paper, we
  International Environmental Modelling and Software Society (iEMSs)7th Int. Congress on Env. Modelling and Software, San Diego, Ca, USA,Daniel P. Ames, Nigel W.T. Quinn and Andrea E. Rizzoli (Eds.)  An ontology-based approach for the instrumentation,control and automation infrastructure of a WWTP Davide Sottara  a , Jean Claude Correale  b , Thierry Spetebroot  b Dalila Pulcini  c Daniele Giunchi  d Fabrizio Paolucci  e , Luca Luccarini  ea Arizona State University, Biomedical Informatics Department, 13212 E Shea Blvd 85259 Scottsdale (AZ), ( b DISI, University of Bologna, Viale Risorgimento 2, 40136 Bologna, Italy,(, c Department of Civil and Environmental Engineering, Politecnico di Milano, Piazza L. da Vinci 32,Milano, Italy, ( d HERA SpA, Via Balzella 24, 47122 Forl`ı, Italy, ( e ENEA, UTVALAMB-IDR, Via Martiri di Monte Sole 4, 40129 Bologna, Italy (, Abstract:  The instrumentation, control and automation of wastewater treatment plants (WWTPs) is akey aspect to ensure good performance and lower operational costs. However, control systems areseldom interoperable and standard-compliant. In this paper, we propose a knowledge-based approachwhich decouples the description of the plants and their control strategies from their physical structureand instrumentation. In particular, we propose a semantic model based on ontologies, formalized usingthe W3C OWL2 standard. We have extended the Semantic Sensor Network and created a specializedrepresentation of the WWTP domain, to provide a consistent description of instrumentation (sensorsand probes), actuators and data acquisition systems. We show how this ontology can be used to modeltypical management actions, such as collecting samples or applying a control policy, and their outcomes. Keywords:   ontology; knowledge based control systems; wastewater treatment plants; IEDSS 1 I NTRODUCTION The optimal management of a wastewater treatment plant (WWTP) requires a continuous monitoring ofthe plant state. The biochemical processes taking place in the plant’s tanks must be observed to ensurethat the environment guarantees their maximum efficiency. A less than optimal process may result inthe degradation of the effluent quality, possibly exceeding the limits set by the local legislation. On theother hand, preserving the ideal operating conditions does not only improve the yield of the treatment,but can also lower maintenance and energy costs [Olsson, 2012]. To achieve this goal, plant operatorsshould collect samples from the plant regularly and analyze them to diagnose the actual plant’s condi-tions and plan the appropriate control and maintenance actions. However, Instrumentation, Control andAutomation (ICA) technologies provide the only cost and time- effective solutions Olsson et al. [2005],allowing to monitor a plant in near-real time and to act in a timely fashion. Recently, improvements intechnology have lowered the costs of sensors, data acquisition systems and mechanical and electronicactuators, so that even smaller-scale plants can be instrumented with a reasonable cost/benefit ratio.Equipping the plants has allowed to implement a variety of diagnostic and control strategies, aimed atimproving the process, preventing malfunctionings and reducing operational costs. These strategies areimplemented within Environmental Decision Support Systems (EDSS), which combine methods fromstatistics [Yoo et al., 2004] and artificial intelligence [Luccarini et al., 2010] with varying degrees of suc-cess [D¨urrenmatt and Gujer, 2012]. Most of the times, however, the control logic is either hardcodedinto the devices that collect the data and command the actuators, or is implemented directly on top of  D. Sottara et al. An ontology-based approach for the instrumentation, control and automation infrastructure of a WWTP  the interfaces provided by the devices themselves. The tight coupling between the control logic and theplant’s equipment makes it difficult to port the controllers between different plants. Instead, if standardsexisted and were supported, the control strategies and the hardware could be deployed, replaced andupgraded independently. In fact, in a typical scenario, a manager responsible for multiple plants wouldlike to apply policies based on the plants’ class (e.g. traditional continuous flow, sequencing batch reac-tor, membrane bio-rector, ...) and scale, rather than the specific type and brand of equipment installedin each plant. In this paper, we propose an initial step in the direction of the standardization of theinterface between control systems and hardware. Our approach is based on semantic web technolo-gies [Berners-Lee et al., 2001]: we have extended and combined the popular Semantic Sensor NetworkOntology (SSNO) [Compton et al., 2012] and the Measurement Unit Ontology (MUO) [MUO, 2008] tocreate a new modular ontology, called OntoPlant. This ontology includes concepts and properties todescribe the topology of a WWTP, its instrumentation and the data and policies that would be generatedby the sensors and controllers. The ontology, instead, does not describe the processes themselves andthe control logic. In fact, a semantic description of the former could be provided by the OntoWEDSSontology [Ceccaroni et al., 2004], while the latter are better represented using other models such asbusiness rules, decision trees or workflows [Sottara et al., 2012]. Our ontology, however, provides theconcepts and the vocabulary which can be used both by human operators and the control systems torepresent the data, the actions and the context where they are generated. In particular, we focusedon four typical scenarios: i) describing the plant, ii) acquiring data automatically through the sensors,iii) acquiring manual samples to perform laboratory tests and iv) defining control interventions. We willuse the scenarios to present the OntoPlant ontology and its architectural principles in Section 2, whilein Section 3 will discuss how the concepts can be applied concretely to a real plant, using a pilot scaleWWTP as a concrete use case. 2 M ATERIALS AND METHODS PilotPlant  Thepilotplant, locatedinsidetheareaofthemunicipalWWTPinTrebbodiReno(Bologna),is fed with real wastewater and composed of a pre-denitrification tank (95 L), an oxidation tank (162 L), asecondary sedimentation tank (85 L). Three peristaltic pumps (for influent loading, internal and externalrecycle), a stirrer and a variable-flow blower are included. It is also provided with probes to measurepH, redox potential (ORP), NH4+-N, NO3–N in the anoxic tank and pH, ORP, DO, NH4+-N, NO3–N andTotal Suspended Solids (TSS) in the aeration tank. Ontologies  An ontology “is a formal, explicit specification of a shared conceptualization” [Gruber,1995]. The corpus of knowledge about WWTPs is a fitting candidate for such a conceptualization. Froman operator’s perspective, the concepts required to run a plant are relatively stable and well-defined, butthe ability to share information is likely to be a more critical aspect. Usually, companies operating inthe water treatment market manage several dozens (if not hundreds) of plants. The lack of a commonframework to describe the plants and the data collected about their functioning limits a company’s abilityto operate and grow efficiently. In fact, multi-utilities such as Hera s.p.a. ( areprogressively centralizing the management activities using remote control technologies, but the integra-tion of the different local platforms often not designed for a distributed environment is currently a majorissue. To create such a common ontology, we have chosen the OWL-2 DL language W3C [2012]. Inaddition to being a W3C standard, it has a number of other benefits. It can be consumed both by do-main experts and machines, so it facilitates the development of knowledge-based software applications.It is designed for the (Semantic) Web, so it is compatible with a distributed environment. It is a formallanguage based on a fragment of first-order logic, which supports some types of automated reasoningsuch as the detection of inconsistencies or the classification of new data (in particular, the DL sublan-guage provides a good compromise between expressivity and computational complexity). Finally, thereexist a number of general purpose ontologies which can be reused in more specific domains such asthe WWTP one. One of these “horizontal” ontologies is the SSNO, which provides the core conceptsnecessary to describe  Sensors  and  Observations . All concepts are defined in a very broad sense.A  Sensor  is an entity which, through a  Sensing  process, observes the  Property  of some  Feature ofInterest  in the context of an  Observation . The SSN ontology, in turn, is built on top of the upper on-tology DOLCE ( ), which definesan even more general layer of abstraction. Among others, it defines concepts such as  Agent ,  Event  and InformationObject . The concepts in the SSN/DUL are too general to be used directly for the WWTP  D. Sottara et al. An ontology-based approach for the instrumentation, control and automation infrastructure of a WWTP  domain, so we have created appropriate subclasses specifically for the description of treatment plantsand their management. Figure 1.  The OntoPlant ontology.The OntoPlant ontology is actually given by the combination of four different modules, as shown in Figure1. The first module, the OntoPlant core, serves two purposes. First, it imports both the SSNO and theMUO, which provides the concepts necessary to model quantities and measures. Second, it completesthe SSNO, adding the notion of  Actuators  /  Actuations  and refining the model of the  Devices . An Actuator  is the dual counterpart of a  Sensor : an entity which can influence the state of a  Property : thecontext in which this action takes place is an  Actuation . In general, even a human operator might qualifyas a  Sensor  /  Actuator : to model the hardware installed on a plant, we have defined the subclasses SensingDevice  and  ActuationDevice , respectively.  Devices  can be connected through  Ports , whichhave  Interfaces  that provide the specification of their functionalities. A  Port , in general, is an entitythat allows the exchange of materials or information between an object and the external world. Theexact nature and modality of this exchange is defined by the interface(s) exposed by the port. Noticethat the OntoPlant module is still as much domain-agnostic as possible: the WWTP-specific conceptsare introduced in a separate module called OntoPlantWWTP. This ontology defines the  Plants  and theirmacro-components ( Tanks ,  Settlers , ...), the  Processes  that take place within the plant, such as the NitrificationProcess  or the  SettlingProcess  and the  Quantities  of interest which are needed toobserve the status of the processes. 3 R ESULTS AND DISCUSSION 3.1 Case Studies The OntoPlantWWTP ontology and its dependencies are intended to provide the background knowledgeto create semantic models of WWTPs. Individual plants, their instrumentation, the samples acquiredsand the control actuations can all be represented as related individuals, instances of the classes andproperties defined in the ontology. In particular, we have focused on four main use cases, which fromour experience cover most of the routine requirements of a plant operator and/or an IEDSS trying tomanage a WWTP, using, as a reference, the pilot plant introduced in Section 2. UC1 : Plant Topology  The main requirement is the ability to model the plant, its topology, the hy-draulic pathways and the instrumentation installed on the plant itself. Using the concepts defined inthe OntoPlant ontology, a  Plant  can have one or more  PlantLine , a  System  with a number of  Tanks .The description of individual plants can use more specific subconcepts. The Trebbo plant is actually an ActivatedSludgeWWTP  with a single, traditional  CASPlantLine  composed by a  DenitrificationPlant ,a  NitrificationPlant  and a  Settler . The sub  Systems  such as the  Tanks  are defined in terms of the  D. Sottara et al. An ontology-based approach for the instrumentation, control and automation infrastructure of a WWTP  treatment  Processes  that take can place therein, including  PrimaryTreatments ,  SecondaryTreatments such as  Nitrification  and  Denitrification ,  Disinfection ,  WasteDisposal  and so on.The layout of the plant is described by the connections between the tanks. In fact,  Tanks  can have HydraulicPorts , a special type of  Port  whose  Interfaces  support the flow of liquids. Through thedistinction between  InputPorts  and  OutputPorts  and their connections it is possible to define thecomplete topology of the plant. For example the  NitrificationTank  has three  InputPorts  and two OutputPorts . One of the input ports is connected to the output port of the  DenitrificationTank , oneis linked to the output port of the settler and the third is used to describe the internal recirculation. Thetwo output ports model, respectively, the internal recirculation itself and the piping to the settler. Oncethe structure of the plant has been defined, it is possible to describe the plant’s instrumentation. Wedistinguish several categories of  Devices , but all devices are deployed in a particular  System .  Plants , PlantLines  and  Tanks  are all subtypes of  System , so a  Device  can be placed with the granularity thatis appropriate, also depending on the accuracy of the knowledge about the plant. The  Devices  arethen distinguished between mechanical devices, such as  Blowers  and  Pumps , instrumentation devicessuch as  Probes  and electronic devices used to interface the instrumentation with the control software(including an EDSS). The notion of  Port  is instrumental in the definition of devices and their proper-ties. For example, a  Probe  is a  SensingDevice  (which in turn is a  Device ) with a  Port  that exposesone or more  MeasurementInterfaces . A measurement interface exposes the ability to measure some ChemicalQuantity  (e.g. pH, concentration) or  PhysicalQuantity  (e.g. temperature, flow rate). Thedistinction between ports and interfaces is needed because modern probes are multi-function sensorswhich can measure more than a quantity at a time, and may expose the values through multiple channelsin different formats. In a similar fashion, a device’s port is considerd an  InputPort : some input ports,used to send commands to a controllable device are further classified as  ControlPorts . For example,the hydraulic pump used for the internal recirculation in the plant’s  NitrificationTank  has two inputports and one output port: the port used for the hydraulic intake, the port used for the hydraulic outputand the control port used to regulate the rate. The latter, in particular, has two alternative interfaces: amanual interface, accessible through a display on the device itself, and an analogic interface that allowsto set the number of revolutions per minute using an appropriate voltage. As always, ports allow to defineconnections, both between devices and the other (sub)systems such as the tanks or the pipes. Usingthese concepts, it is possible to define the instrumentation of the Trebbo plant, which is equipped withpH, redox potential (ORP) and temperature probes in the anoxic tank, and pH, ORP, dissolved oxygenconcentration (DO), nitrogen (NH4-N and NO3-N) and suspended solids (TSS) probes in the aerobicone, three peristaltic pumps (load, internal and external recycle) and a blower. All analogic probe sig-nals are sampled and acquired in current (4-20 mA) by a stand-alone data logger (Datataker DT80), atthe rate of 1 sample/min, while all the actuators are regulated in current (4-20 mA), by an AdvantechADAM 5000 module, driven by the DT80. UC2: ManualSampleCollection  Thedescriptionoftheplantenablesanumberofotherusecases. Atypical management operation is the collection of one or more samples in the plant’s tanks. The samplesare sent to a laboratory where routine chemical analysis are performed to check that the concentrationsof the pollutants in the tanks are within the allowed limits. The OntoPlant ontlogy provides the conceptsto describe the samples, the context in which they were acquired and the result of the analysis performedon the samples themselves.The act of gathering a  Sample  is a specific type of  Observation , a  Situation  taking place at a given TimeInstant , where a  Sensor  performs an act that has a result, in this case the  Sample  itself. A  Sample is acquired in a  CollectionPoint , which is located inside a (sub) system such as a  Tank . The positionof the collection point can be specified using the exact coordinates, or left undetermined. Using theOntoPlant ontology, the results of the analysis of the  Sample  can be modelled as well. In this secondphase, the srcinal sample itself is the subject of the  Observation : the content of the sample is the FeatureOfInterest  whose  Properties  are measured to obtain the desired  QualityValues , expressedin terms of a quantity and a unit of measure, concepts taken from the MUO ontology.This model is possibly redundant but accurate. Strictly speaking, the results are qualities of the samplerather than the plant. In fact, the model allows to differentiate between the time when the sample hasbeen collected and the time the analysis have been performed, the method for the collection of thesample and the method(s) used for the analysis of each property, and the tools and actors involved in  D. Sottara et al. An ontology-based approach for the instrumentation, control and automation infrastructure of a WWTP  the operations. This historical trace can be used to establish the provenance of the results and theirdegree of reliability, depending on the type of analysis that have been performed. For a result to reflectthe state of the plant accurately, it is necessary that the sample is acquired from an appropriate locationin the tank (modelled by the  CollectionPoint ), using an appropriate method (e.g. by pre-filtering thesample) and that the chemical analyses are performed in a timely fashion (modelled by the comparisonof the  TimeInstants ) and suitable techniques. The automated assessment of the provenance of asample and the validation of the result of the analysis may have technical and legal implications whichwill the subject of future studies. UC3 : Plant Equipment and Automatic Sampling  Probes measuring quantities such as pH, tem-perature, and dissolved oxygen concentration require minimal investments, while more sophisticatedsensors for quantities such as nitrates and other ammonia compounds are still more expensive, butmanageable especially in large-scale plants. These sensors can potentially acquire a vast amount ofdata which, while useful to continuously trace the state of the processes, necessarily require some kindof automated management and large amounts of space for data storage. The advent of stable internetconnectivity and, more recently, cloud-based solutions makes a centralized, remote management of thedata a feasible option, especially when an organization is managing multiple plants.However, this approach has to deal with two main challenges: the diversity of the instrumentation in-stalled on each plant and the necessity to distinguish the source of the various data streams. TheOntoPlant ontology has been designed to deal with both issues. First of all, it provides an abstractionlayer that can be used to describe the various devices in terms of their functionality rather than thespecific brand or technology. A  SensingDevice , like other  Devices  has  Ports  that expose  Interfaces ,physical or logical, that can be connected or mapped respectively.  SensingDevices , more specifically,are  Sensors  that can measure the  QualityValues  of one or more  Properties  directly. The measure isan instantaneous  Observation  performed by the probe using the methodology built in the probe itself.Unlike a manual sampling, there is no need to create an explicit  Sample  since the two steps (collectionand analysis) usually coincide. However, probes are installed in a  CollectionPoint , so that the prove-nance of the results can still be established. The values computed by the probes are accessible throughat least one of their  Interfaces , which models the endpoint of the concrete communication channelused to acquire or download the data.From a data acquisition system’s perspective, the ontology allows to describe the context where a “num-ber” is generated, so the values can be completely qualified even in a distributed environment. If URIsare used to denote individuals, as recommended by the standard, the risk of ambiguities is removed.The linked and graph-oriented nature of the semantic data model allows to decide how much data shouldbe shared between two endpoints so that both can share the same information. In particular, if a dataacquisition system installed locally on a plant and a remote data center share the same description ofthe plant, as per the first use case discussed, it is merely sufficient to communicate the  QualityValues acquired by each probe to keep the two systems synchronized, thus minimizing the amount of networktraffic. UC4 : Control and Actuation  The approach used for the data acquisition can be reversed andadopted for (automated) control. Most plants allow for some form of control over time: the changeof a recirculation rate or the amount of air blown in an oxidation tank are two basic and common exam-ples. However, control policies are usually defined in terms of a target goal (e.g. the nitrogen compoundor the oxygen concentration in a tank) and a manipulation variable (e.g. a pump’s rpm or a blower’s flowrate). A logical command such as “ set the pump speed to 20rpm  ” has to be translated into a specificsignal delivered to a specific channel which is normally device-specific. The OntoPlant ontology allowsto decouple the two steps: the high-level commands can be formulated in terms of  Actuations  the dualcounterpart of an  Observation  , which set the  Property  of a  Device  to the desired  QualityValue , asalways expressed by a unit/value pair. In particular, the actuation is targeted to an  Interface  exposedby a  Port  of the device. The semantic representation, as always, leverages the description of the plantand its equipment, also defined using the concepts in the ontology. The abstraction provided by thedeveloped semantic model allows to decouple control policies from hardware configuration (Figure 2).The control system, regardless of whether it is an interface for an operator or a full EDSS, can issuethe commands in a format which is independent of the specific device, but is focused on the desiredfunctionality. The assumption is that local equipment is enhanced with a device-specific driver that can
View more...
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!