Dutch technical agreement. NTA (en) System Interface AMI Systems Part 1: System Software API

Transcription

1 Dit document mag slechts op een stand-alone PC worden geinstalleerd. Gebruik op een netwerk is alleen. toestaan als een aanvullende licentieovereenkomst voor netwerkgebruik met NEN is afgesloten. This document may only be used on a stand-alone PC. Use in a network is only permitted when a supplementary license agreement for us in a network with NEN has been concluded. Dutch technical agreement NTA (en) System Interface AMI Systems Part 1: System Software API Systeeminterface AMI-systemen Deel 1: Systeemsoftware API ICS June 2010

2 Normcommissie "Interconnection of information technology equipment" Apart from exceptions provided by the law, nothing from this publication may be duplicated and/or published by means of photocopy, microfilm, storage in computer files or otherwise, which also applies to full or partial processing, without the written consent of the Netherlands Standardization Institute. The Netherlands Standardization Institute shall, with the exclusion of any other beneficiary, collect payments owed by third parties for duplication and/or act in and out of law, where this authority is not transferred or falls by right to the Reproduction Rights Foundation. Auteursrecht voorbehouden. Behoudens uitzondering door de wet gesteld mag zonder schriftelijke toestemming van het Nederlands Normalisatie-instituut niets uit deze uitgave worden verveelvoudigd en/of openbaar gemaakt door middel van fotokopie, microfilm, opslag in computerbestanden of anderszins, hetgeen ook van toepassing is op gehele of gedeeltelijke bewerking. Het Nederlands Normalisatie-instituut is met uitsluiting van ieder ander gerechtigd de door derden verschuldigde vergoedingen voor verveelvoudiging te innen en/of daartoe in en buiten rechte op te treden, voor zover deze bevoegdheid niet is overgedragen c.q. rechtens toekomt aan de Stichting Reprorecht. Although the utmost care has been taken with this publication, errors and omissions cannot be entirely excluded. The Netherlands Standardization Institute and/or the members of the committees therefore accept no liability, not even for direct or indirect damage, occurring due to or in relation with the application of publications issued by the Netherlands Standardization Institute. Hoewel bij deze uitgave de uiterste zorg is nagestreefd, kunnen fouten en onvolledigheden niet geheel worden uitgesloten. Het Nederlands Normalisatie-instituut en/of de leden van de commissies aanvaarden derhalve geen enkele aansprakelijkheid, ook niet voor directe of indirecte schade, ontstaan door of verband houdend met toepassing van door het Nederlands Normalisatie-instituut gepubliceerde uitgaven Nederlands Normalisatie-instituut Postbus 5059, 2600 GB Delft Telefoon (015) , Fax (015)

3 Contents Introduction and preface Scope Normative references Terms and definitions General Symbols and abbreviations Energy abbreviations Other abbreviations AMI NTA Usage of NTA NTA 8150 API Introduction to the API Parameter XML structure Returned XML structure IDs Date time field Ellipsis ( ) Optional nodes Plural nodes Additional information: Return codes Version changes Constants API managers AttributeManager DeviceManager EventManager FirmwareManager GatewayManager ScheduleManager Results data General structure Results for billing data Device event log data Gateway WAN configuration data Instantaneous power data Load profile & delta load profile data Maximum power level duration Power quality data Time-of-use data Constant definitions

4 Introduction and preface Smart metering is a fact. It will be implemented due to regulation or business need. The EC Energy Services Directive enforces member states to act to ensure awareness for energy usage is raised at consumer level. Meanwhile, the need for a smart grid is raising. New circumstances like local generation of energy, distributed generation and electrical cars create a world for which the current grid was not designed. The information generated at a meter level is differentiated for various usergroups; retailers, grid manageres, third party service providers. The physical connection will come in various flavors, powerline communication (PLC), wireless (RF) and with different protocols suited for that communication. Therefor, interoperability between the systems, applications, needs to be ensured independent of these physical layers. This can be achieved using an higher level protocol, like webservices. This document describes a standard on this level, by which various users can use information in their applications, independent of the underlying technology. The standard is provided and maintained by ESNA, a not-for-profit organization of users and supporters of this concept and architecture. The purpose of this document is to define a national reference architecture to allow applications to be independent of physical communication layers as well as independent of transport, network and transmission protocols. To achieve this goal, an architecture is created including the Application Programming Interfaces to support an AMR/AMI (Automatic Meter reading/automatic metering Infrastructure). The technology used for the API is based on the open standard SOAP/XML. This architecture will support applications for various user groups; suppliers (retailers), DSO or third party service providers. The interfaces should accommodate not only metering applications but grid management in a broader sense. Beside information required for billing and forecasting, information on power quality to support grid management and control to support demand side management are supported by the infrastructure as well. The NTA 8150 consists of: NTA 8150 Part 1: System Software API, description of the architecture and the API for AMI; NTA 8150 Part 2: API usage per use case, description for specific AMI use cases, as examples. After the publication of NTA 8150, the specification is planned to be launched on international level as an CWA through European standards institutes (CEN-CENELEC). 2

5 System Interface AMI Systems Part 1: System Software API 1 Scope This document provides detailed information about the usage of all NTA 8150 API calls. It also contains detailed information about commands, events, solution settings and results and is intended for use by programmers working with this API. 2 Normative references The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies SOAP/1.2 Extensible Markup Language (XML) 1.0 through Web services conforming to W3C standard SOAP/1.2 3 Terms and definitions The following terms and definitions apply throughout this standard. 3.1 General Attribute type The type of the attribute's value. When APIs are called that require an attribute value type, they shall use a valid type unless otherwise stated. For a list of valid attribute types, see the AttributeTypes class in Chapter 9, Constant definitions Authentication key A general term referring to the keys that secure electronic access to meters and Data Concentrators. Authentication keys include the Provisioning Key, Unique Key, Read-Only Key, User-Defined Key, and LonTalk Key Cause code An error code indicating why a request was not successful Continuous Event Log (CEL) A process on the Data Concentrator that you can configure to return just the unread event log data from a meter during normal priority communications and during gateway-initiated communications Coincident source Two data sources per demand register captured at maximum demand update Command history status type An ID that identifies a status of command history in the solution. For a list of valid command history status types, see the CommandHistoryStatus class in in Chapter 9, Constant definitions Commission A meter is commissioned when the Data Concentrator can establish authenticated communication with a meter. 3

6 3.1.8 Communication type The types of communication in the solution. When APIs are called that require a communication type, they shall use a valid type unless otherwise stated. For a list of valid communication types, see the GatewayCommunicationTypes class in Chapter 9, Constant definitions Continuous delta load profile A command that is rescheduled every time a delta load profile result for that command is processed until the command times out Control relay Managing energy output on a meter. You can configure the switching mechanism to work either as a simple on/off switch or as a switch that you can further manage through tiers Credit overflow The amount of prepay credit that was not added to the meter because it exceeded the meter s credit limit Data order types MSB First: The most significant byte of a multi-byte record is first. LSB First: The least significant byte of a multi-byte record is first Delta load profile data A load profile result that contains the portion of load profile data that has not been previously read from the meter Device limit The number of devices that a Data Concentrator can supervise Device status type An ID that identifies a status of a device in the solution. For a list of valid device status types, see the DeviceStatus class in Chapter 9, Constant definitions Device type An ID that identifies the type of a device in the solution. When APIs are called that require a device type, they shall use a valid type unless otherwise stated. For a list of valid device types, see the DeviceTypes class in in Chapter 9, Constant definitions Discovered device A device that a Data Concentrator can communicate with, but it is not currently configured on that Data Concentrator Engine command type The types of engine (task processor) commands in the solution. When APIs are called that require an engine command type, they shall use a valid type unless otherwise stated. For a list of valid engine command types, see the TaskProcessorCommands class in Chapter 9, Constant definitions Entity type ID The kinds of entity types in the solution. When APIs are called that require an entity type ID, they shall use a valid type unless otherwise stated. For a list of valid entity type IDs, see the EntityTypes class in Chapter 9, Constant definitions Event delivery status type The types of event delivery status possible for an event delivery. When APIs are called that require an event delivery status type, they shall use a valid type unless otherwise stated. 4

7 Event delivery type The types of delivery available for an event. When APIs are called that require an event delivery type, they shall use a valid type unless otherwise stated. For a list of event delivery types, see the EventDeliveryTypes class in Chapter 9, Constant definitions Event status type The status of events. When APIs are called that require an event status type, they shall use a valid type unless otherwise stated Export reactive energy Reactive energy delivered by the customer. The value is measured in volt-amps reactive hours Firmware Software that can be used to update a Data Concentrator or meter to a newer version Flash low A Data Concentrator event that indicates that memory available on the Data Concentrator is low Forward active energy Energy consumed by the customer. The value is measured in watt-hours Forward power The power generated by a utility and being consumed by a customer Gateway communication request type The types of gateway communication requests in the solution. When APIs are called that require a gateway communication request type, they shall use a valid type unless otherwise stated Gateway communication status type The types of gateway communication statuses in the solution. When APIs are called that require a gateway communication status type, they shall use a valid type unless otherwise stated Gateway communication type The way the gateway communicates. When APIs are called that require a gateway communication type, they shall use a valid type unless otherwise stated Gateway status The current status of a gateway. When APIs are called that require a gateway status, they shall use a valid status unless otherwise stated Gateway template type The way the gateway can be used as a template. When APIs require a gateway template type, they shall use a valid type unless otherwise stated Gateway type The type of gateway. When APIs require a gateway type, they shall use a valid type unless otherwise stated Gateway Wide Area Network (WAN) configuration The WAN Configuration on a Data Concentrator. 5

8 Global task manager A Windows Service that monitors the running task processors (engines) to ensure that they are functioning as expected Hierarchy level member retrieval type What to search in when a hierarchy level member does a search. When APIs are called that require a hierarchy level member retrieval type ID, they shall use a valid type unless otherwise stated ID type Used when calling the RetrieveByParameter APIs Instantaneous power data An on-demand reading of the meter s phase, power voltage and power quality values, which involves connecting to the meter using DeviceManager.PerformCommand API Internal expansion module card An optionally-installed Internal Expansion Module card Import reactive energy Reactive energy consumed by the customer. The value is measured in volt-amps reactive hours Load profile block A time period that represents a set of load profile intervals. Interval data is not available for a Read Device Delta Load Profile command or a Continuous Delta Load Profile until the load profile block is complete. Partial load profile blocks are available to the Read Device Full Load Profile command Load profile data The recording and storage of data over a period of time by a particular meter. The entire set of load profile data is contained within the queue on a meter Load profile interval Defines the frequency at which the meter records load profile usage data Local task manager A Windows Service that runs on a server that starts task processors (engines) on the same server Maximum power A setting that configures the meter to use the maximum power feature set within the meter M-Bus device A meter bus device, for example, a water or gas meter. You can attach an M-Bus device to a meter device, which allows them to communicate with each other Message log status type The types of message log statuses in the solution. When APIs are called that require a message log status type, they shall use a valid type unless otherwise stated Message log type The types of message logs in the solution. When APIs are called that require a message log type, they shall use a valid type unless otherwise stated. 6

9 Meter authentication key See Authentication Key Nascent Condition of a meter that has not yet been commissioned successfully or was commissioned but then suffered a non-volatile memory failure. This condition can also occur if the meter was added with an incorrect authentication key Neuron ID A twelve hexadecimal character value that uniquely identifies a Data Concentrator or meter in the system On-demand billing data An instantaneous reading of the meter s billing data Orphaned communication Occurs when a communication is left open and no longer processed against. For example, if a Data Concentrator is given an incorrect hello IP address, when the server connects to the Data Concentrator it will result in an orphaned communication Orphaned device A device that is commissioned on a Data Concentrator although the Data Concentrator cannot communicate with it. However, a different Data Concentrator can communicate with that device and knows that the device is not communicating with the Data Concentrator that it is commissioned on Outage duration threshold Time threshold, in seconds, for recording power outages Overcurrent event Some percentage over a meter s maximum current rating, specified by overcurrent threshold, on any one phase for at least ten seconds. The number of overcurrent events are recorded per phase Overcurrent threshold Threshold, in percent over maximum current, for recording an overcurrent event Priority Continuous Event Log (PCEL) A process on the Data Concentrator that you can configure to return unread event log data from a meter when device alarm events occur that are configured for priority continuous event logging Power Line Carrier (PLC) A Data Concentrator communicates with meters via the power line Power outage threshold Time threshold, in minutes, for recording power outages, voltage sags and surges Power quality data Data that is returned as a result of sending the Read Device Power Quality command through the DeviceManager.PerformCommand or DeviceManager.PerformCommandOnGroup API Pulse input The meter s count of pulse data. You can read and configure the channel minimum pulse width and two pulse inputs (channel 1 and channel 2) of a meter. 7

10 Repeater A device in a repeater path through which a message passes on its way to the target device Repeater paths A sequence of repeaters through which a message shall travel to reach its intended target device Result type The types of results in the solution. Result types are divided into two categories: device result types and gateway result types Reverse active energy Energy delivered by the customer. The value is measured in watt-hours Reverse power Power generated by a customer that flows back through the meter Sag event Voltage on a single phase dipping below some percentage of the rated voltage for time specified by the Sag Voltage Percent Threshold setting. The number of sag events are recorded per phase Sag/surge duration threshold Time threshold, in minutes, for recording voltage sags and surges Sag threshold Threshold, in percent under rated voltage, for recording a voltage sag event Season A Time-Of-Use calendar partition that contains one of four possible values, with indexes 0 3. Each season has a start and end date and is defined on the meter Secondary billing registers Continuously increment with each day's energy and are updated once per day at UTC midnight Security key Refers to the API Security Key obtained from UserManager.Login. The API Security Key (skey) is required for each API call Server WAN configuration Defines characteristics of a WAN Configuration for a type of communication within the solution. For example, the number of outbound communications for the gateway communication type is defined within the WAN Configuration Server WAN configuration route Defines how a communication mechanism will manage connections within the solution Source code IDs load profile Source code IDs are sometimes referred to as Channel IDs in the XML for load profiles Standard billing data Standard (end of billing cycle) billing data contains information such as the tier, the date time the data was collected, and so on. 8

11 Surge event Voltage on a single phase going above some percentage of the rated voltage for time specified by the Power Quality Surge Voltage Percent Threshold setting. The number of surge events are recorded per phase Surge threshold Threshold, in percent over rated voltage, for recording a voltage surge event Tariff A published list of rate schedules, terms and conditions. Or, the particular rate in effect at a given time. See Tier Task A logical unit of work. For example, an event that needs to be processed or a scheduled item that needs to be processed Task processor type A process that completes tasks of a specific type or the types of task processors (engines) in the solution. When APIs are called that require a task processor type, they shall use a valid type unless otherwise stated. For a list of valid task processor types, see the TaskProcessorTypes class in Chapter 9, Constant definitions Task status type The types of task status in a solution. When APIs are called that require a task status type, they can use any of these valid types unless otherwise stated. For a list of valid task status types, see the TaskStatusTypes class in Chapter 10, Constant definitions Test point The meter on a segment (the physical wiring for the power line grid) which is used to determine if the status of the segment is up or down Tier A tier usually refers to a single tariff or its associated registers in the meter. Tier can be synonymous with tariff. Billing data is recorded based on the active tier Tier register Energy usage is partitioned into different tier registers based on a schedule. A meter supports four tier registers. The tiers are selected for different time periods within a day Tier switch The time at which a tier register is changed Time-of-use (TOU) calendar A TOU calendar contains TOU schedules. There are two types of TOU calendars: Active and Pending Time-of-use (TOU) schedule The partitioning of energy usage into different tier registers based on a schedule. The TOU schedule is a list of tariffs assigned to each tier register. There are three types of TOU schedules (which you can add or modify): recurring dates schedules, day schedules, and season schedules. The three types of schedules are defined for a TOU calendar. There are two types of TOU calendars: Active and Pending Time zone ID An ID that identifies a time zone in the solution. To obtain a list of time zone IDs, call the TimeZoneManager.RetrieveList API. 9

12 Total energy The sum of the previous day's energy for every phase of every meter under a Data Concentrator Tracking ID A key that tracks a command throughout its life Unique key Grants access to a meter or a Data Concentrator through the optical port or to a Data Concentrator over the WAN Utility ID An ID that can be assigned to a meter device that the customer chooses. For example, a utility may wish to designate the customer ID from the customer management solution used by the utility as the utility ID. 4 Symbols and abbreviations This chapter lists symbols and abbreviations that are used throughout the document. 4.1 Energy abbreviations The following are some common abbreviations for energy measurements. Measurement A Hz kw kwh kvar PF var Varh V VA W Wh Amperes Hertz Kilowatts Kilowatt hours Definition Kilo volt ampere reactive Power factor Volt amperes-reactive Volt ampere reactive hour Volts Volt ampere Watts Watt hours 10

13 4.2 Other abbreviations BIDN TOU UTC Billing Interface Definition Number - an identifier for a billing configuration. The meter does not generate this value it shall come from a client configuring the billing configuration on the meter. Time-of-Use. The partitioning of energy usage into different tier registers based on a schedule. The TOU schedule is a list of tariffs assigned to each tier register. Universal Time Coordinated (zulu or Greenwich Mean Time, GMT). WAN Wide area network Meters 5 AMI Advanced Metering Infrastructure (AMI) refers to systems that measure, collect and analyze energy usage, from advanced devices such as electricity meters, gas meters, and/or water meters, through various communication media on request or on a pre-defined schedule. This infrastructure includes hardware, software, communications, customer associated systems and meter data management (MDM) software. Figure 1 shows the architecture of a typical AMI system. Billing CIS Prepay Reporting EMS Outage Middleware Web Service API AMI System Manager IP WAN Concentrators Concentrators Meters Figure 1 AMI System Architecture The network between the measurement devices and business systems allows collection and distribution of information to customers, suppliers, utility companies and service providers. This enables these businesses 11

14 to either participate in, or provide, demand response solutions, products and services. By providing information to customers, the system assists a change in energy usage from their normal consumption patterns, either in response to changes in price or as incentives designed to encourage lower energy usage use at times of peak-demand periods or higher wholesale prices or during periods of low operational systems reliability. AMI expands the scope of traditional Automatic Meter Reading (AMR) in that it enables two-way communications with the meter. Traditional systems which were only capable of meter readings don't qualify as AMI systems. There are many dramatic differences between AMR and AMI, and AMI systems provide much more. AMI includes the use of smart meters in addition the network is the core component of a true AMI system. The AMI networked system needs to be scalable, expandable and flexible to future proof the system. True AMI systems create a paradigm shift in the utility industry and can drive a change in generation planning, energy pricing, demand reduction, asset optimization, theft and fraud reduction, and smart metering data. AMI supports increased meter functionality, TOU tariffs, demand response, remote disconnect and reconnect, in-home applications, as well as improvements in customer service, utility operations, and revenue recovery. Since AMI provides an extensive variety of new functions and services, it therefore has a dramatic impact on IT integration and business processes. 5.1 NTA 8150 To fully realize the benefits of AMI and the smart grid, it shall be able to exchange data between disparate utility systems. These systems often use a variety of data exchange formats and mechanisms that have historically prevented the systems from effectively communicating with each other. To address this, the Internet community has already developed Web services (SOAP/XML), a standards-based way for applications to integrate with each other. Web services use ubiquitous protocols and the Web infrastructure that exists in every organization, so they require little, if any, additional technology or training investment. The inherent interoperability that comes with using vendor-, platform-, and language-independent Web services technologies is vital in obtaining the maximum benefits from smart grids and advanced metering systems for the least amount of integration costs. In the market of Advanced Metering Infrastructures (AMI) solutions and systems, there is no public standard for a system level interface. NTA 8150 provides standardization at the physical communication layer and transport, communication and transmission networks used by AMI systems. NTA 8150 also provides a foundation to stimulate the market, and provides a stable and sustainable basis for innovation. While providing a basis for innovation, NTA 8150 also serves to help avoid the re-development of concepts that are already used in other metering systems, and protects developers from version dependencies. NTA 8150 is provided as an object-based, system-level application interface that exposes Extensible Markup Language (XML) 1.0 through Web services conforming to W3C standard SOAP/1.2, providing for secure access to metering data, and scaling to support millions of meters. It provides common methods applicable to all metering systems as well as architected mechanisms for system-specific extensions. As shown in Figure 1 above, NTA 8150 would function as the Web Service API. A web services interface at the IT integration layer simplifies integration with billing, customer care, outage management, and other applications and insulates and protects enterprise software investments. NTA 8150 defines an API to a virtual device or meter which enables utilities to maintain and leverage their large investment in IT systems and applications and allow them the option to work with a variety of underlying metering systems. This approach allows utilities to take advantage of the largest competitive market possible and also enables them to take advantage of new technologies as they emerge from any potential vendor. An additional benefit of standardizing at the enterprise level is that this will leverage and optimize the implementation of multiple smart grid applications rather than focusing on a single application, such as metering. The implementation of a specific metering interoperability standard limits innovation and promotes the smart grid as a point solution rather than as an enterprise infrastructure for an entire corporate solution. Interoperability at the web services layer along the lines of NTA 8150 protects investment in infrastructure systems. Technical deployments based on NTA 8150 will be applied by suppliers, developers and manufacturers of gauges and measuring devices to support the many different energy metering requirements in the market. 12

15 The deliverables of NTA 8150 will consist of Description of the architecture and the API for AMI. This is included in this document. API usage for specific AMI use cases, as examples. This is included in the System Interface AMI Systems Part 2: API Usage Per Use Case document. 5.2 Usage of NTA 8150 NTA 8150 based applications enable you to communicate with devices (e.g. meters, Data Concentrators and in-home equipment), to provide the service types listed below: Infrastructure management You can use NTA 8150 based applications to manage the AMI infrastructure (grid topology). For example, NTA 8150 provides services for tasks such as adding and removing meters; setting up associations between meters, customers, Data Concentrators, and transformers; altering Data Concentrator configuration; managing communication, and loading new Data Concentrator and meter firmware remotely so that new services can be added without replacing the field hardware. NTA 8150 based applications can also include features that assist in the discovery of devices and associations of meters. Data Concentrators and other inhome devices Device management You can use NTA 8150 based applications to remotely manage meters and connected devices like M-Bus devices. For example, you can load new operational data into meters and send commands to meters for tasks such as load limiting and disconnecting or reconnecting electricity service for a meter Event management You can use NTA 8150 based applications to receive and distribute events that are reported by the system. For example, you can track meter tampering, power outages, operation status, programming changes, and alarms Data collection You can use NTA 8150 based applications to collect meter information such as billing data, load profiles, and power quality from Data Concentrators. You can automate the collection of this information by setting up a connection schedule to configure NTA 8150 based applications to periodically connect to the Data Concentrators, meters or other devices in general. These services are exposed through NTA 8150 Web services API. You can access the NTA 8150 APIs directly or you can set up utility enterprise applications to use the APIs to orchestrate the NES system. NTA 8150 describes each of the APIs Systems integration NTA 8150 simplifies and secures integration with utility and third party systems including applications associated with billing, customer care, demand management, outage management and other traditional applications, as well as future undefined applications NTA 8150 API 13

16 Bestelformulier Stuur naar: NEN Standards Products & Services t.a.v. afdeling Klantenservice Antwoordnummer WB Delft NEN Standards Products & Services Postbus GB Delft Vlinderweg AX Delft Ja, ik bestel ex. NTA :2010 en Systeeminterface AMI-systemen - Deel 1: Systeemsoftware API T (015) F (015) Wilt u deze norm in PDF-formaat? Deze bestelt u eenvoudig via Gratis nieuwsbrieven Wilt u op de hoogte blijven van de laatste ontwikkelingen op het gebied van normen, normalisatie en regelgeving? Neem dan een gratis abonnement op een van onze nieuwsbrieven. Gegevens Bedrijf / Instelling T.a.v. O M O V Klantnummer NEN Uw ordernummer BTW nummer Postbus / Adres Postcode Plaats Telefoon Fax Factuuradres (indien dit afwijkt van bovenstaand adres) Postbus / Adres Postcode Plaats Datum Handtekening Retourneren Fax: klantenservice@nen.nl Post: NEN Standards Products & Services, t.a.v. afdeling Klantenservice Antwoordnummer 10214, 2600 WB Delft (geen postzegel nodig). Voorwaarden De prijzen zijn geldig tot 31 december 2018, tenzij anders aangegeven. Alle prijzen zijn excl. btw, verzend- en handelingskosten en onder voorbehoud bij o.m. ISO- en IEC-normen. Bestelt u via de normshop een pdf, dan betaalt u geen handeling en verzendkosten. Meer informatie: telefoon , dagelijks van 8.30 tot uur. Wijzigingen en typefouten in teksten en prijsinformatie voorbehouden. U kunt onze algemene voorwaarden terugvinden op: LEREN, WERKEN EN GROEIEN MET NEN preview