This guide ensures the best possible results from Kiona. It covers documentation required for the automation delivery including the IWMAC top-level system. Contact your Kiona representative if you cannot find a template.
Quick guide:
- Download templates and checklists as attached files at the bottom of this article
- Complete the templates and checklists with information about the installation
- Send documentation to support_iwmac@kiona.com
- Kiona will review and follow up if there are questions or further information is required
📘 1 – Design and Integration Guide
1.1 – Purpose
This guide has been prepared to ensure the best possible result from the delivery by Kiona. The guide provides information on the supporting documentation required for the automation delivery. The delivery includes the IWMAC top system and associated additional services. The appendices describe the supporting data needed for the delivery, with specific details for certain installation types and protocols.
All examples and templates are also available on the websites of our Kiona-certified partners.
If you cannot find a template, please contact your Kiona contact person in Sales or Deliveries.
1.2 – Network/IT Infrastructure
Once the delivery has been ordered, an installation server will be sent from Kiona. In order for the delivery to start, contact must be made with the dispatched installation server well in advance of the scheduled start-up. Start making the necessary preparations so that the network will be ready in good time.
It is important that the customer reaches clarification early on with the end customer as to whether the installation server is to communicate with the Kiona cloud over a direct internet connection or VPN. Once Kiona has received the information from the customer, Kiona will order the correct setup from its own network provider.
Once delivery commences, you will receive a standard form for internet connection and VPN connection outlining the information Kiona needs, as well as the configuration the end customer must undertake in order for the installation server to come online. Kiona will not be able to start work until the forms have been returned and the described settings have been verified.
An installation server comes supplied with two network cards. Kiona must be assigned two network connections – this is important information the customer must obtain. It is recommended that one interface is reserved for internet connection and is separate from the technical network. The second interface is connected to the technical network.
Converters provided by Kiona will be configured as part of the delivery once the necessary information has been handed over. For converters not provided by Kiona, Kiona can assist in configuring and installing these on the installation PC. However, this service is not included in the delivery and will be handled as an additional option.
1.3 – Topology
In order to establish a communication connection with all automation devices, Kiona needs a complete topology that lists all the necessary network information. Kiona relies on receiving all information about serial-to-network converters, with an associated overview of which automation devices are connected to the various ports.
See the following examples:
- Graphics: topology in PNG format, produced in Gliffy or similar software – IWMAC TEMPLATE 12 – Topology.png / IWMAC TEMPLATE 13 – Topology.gliffy
- Excel: Simple template for devices on IP, advanced template for devices on IP and serial devices via converters – IWMAC TEMPLATE 10 – Simple topology IP only / IWMAC TEMPLATE 11 – Topology IP and serial converters.xltx
1.4 – Parameter Lists, Tag Names and Descriptions
IWMAC uses names and descriptions received in the supporting documentation from the customer. In certain cases this can be read by scanners directly from the equipment. For Kiona to be able to provide end users with readable and localisable tag names, the data lists must contain the necessary information and a structure that allows Kiona to properly construct the tag databases.
Here are some general guidelines:
- Kiona assumes that a system number and cross-disciplinary labelling system (TFM) component code are entered for each parameter/tag line, as well as a simple parameter description, either by physical component or by function.
- For room control, it must be possible to separate each room, floor and, if necessary, building or wing.
- All similar functions within each room must be given the same function code.
- For higher-level central components and zone-delimited functions, zone/group assignment must be indicated for each parameter line.
- For lists dealing with a device that serves only one system number, the system number can be omitted.
The IWMAC component code standard will be used in images unless otherwise agreed, or if component codes are not in the tag list or associated system schedule. All supporting data must be consistent in character encoding so that Kiona can identify component assignments.
Example for temperature sensor (process value) and parameter for calculated set point:
- 360.001 RT401 Supply air temperature or building_no._360001_RT401_PV Supply air temperature
- 360.001 RT401 Calculated set point or building_no._360001_RT401_ASP working set point
Example for rooms:
- R201_Erverdi – Room temperature
- R201_BasSetp – Base set point
- R201_HVlv – Application of heat
- R201_SQ401_lm – Supply air VAV1 airflow
- R201_SQ402_lm – Supply air VAV2 airflow
- R201_SQ501_spjv – Exhaust VAV1 damper angle
In Modbus, KNX, OPC, N2 and corresponding tag lists, typically both the TFM encoding and description can be part of one and the same text. It is then important that the structure is the same for all lines, with the system component function code in a fixed order – with fixed delimiters first and with the description at the end.
For BACnet objects, TFM encoding can often be included within the object name itself, while the description is appended in the “description” attribute. Other structuring is also possible as long as the tag contains all the necessary information and structure, as previously described.
1.5 – Alarm Functionality and Write Access
Kiona must specify directly in the tag database which items are readable and/or writable. The same applies to alarm level indication for points intended to generate an alarm.
IWMAC normally only requires digital alarms in the database. If the customer wants to generate alarms on multistate (integer) or floating point values, clarification is required with Kiona’s delivery manager as to whether this is possible and what consequences it may have in terms of additional time needed, smart functions required, etc.
See the specific protocol appendix for an outline of the information Kiona requires regarding whether points are to be writable or define alarm points, plus their associated alarm level.
Checklists:
✅ 2.1 – IWMAC Checklist – BACnet
BACnet/IP: device must respond to Who-is. BBMD required for multi-subnet networks. In large networks spanning multiple subnets, the customer must ensure proper IT and BACnet configuration. Kiona needs a topology showing all substations with IP address, subnet mask, gateway, network number, device ID, and BBMD identity (including FDT/BDT table entries).
| Checklist – BACnet device integration | Device:_____________________ | |
|---|---|---|
| Checkpoint | Explanation | Done (Yes/No) |
| The device has been fully commissioned and function tested | ☐ | |
| The device can be pinged from an IWMAC PC | ☐ | |
| Extra columns have been added to the end of the EDE file. | Alarm Pri, Include Attri., Group, Room. See template: IWMAC TEMPLATE 03 – BACNET Ede.csv | ☐ |
| "settable" column adjusted: writable points set to "Y", all others to "N". | Writable points are normally set points, SD switches and similar. | ☐ |
| All points with intrinsic reporting and alarm state enabled are set to "1" in "Include Attri.". | ☐ | |
| A separate list of attributes to be submitted for each data point has been created. | For all objects where "Include Attri." is set to "1". | ☐ |
| Each parameter/line in the EDE file contains system number, component label and descriptive text. | Example: "320.001 RT401 Flow temperature radiator circuit A block". | ☐ |
| If the system number does not appear above, the following two lines must be filled in by the customer. | ☐ | |
| "Group" column filled with system number for all lines in EDE file. | Same number/name for all objects in the same system. | ☐ |
| "Room" column filled for all objects belonging to room control/zone control. | Same room designation for all objects in the same room/zone. | ☐ |
| Alarm level A, B or C specified for all alarm objects. Also filled on lines where "Include Attri." = "1". | A = highest (normally sent by SMS), C = lowest. | ☐ |
| Any NC binary alarms are listed in a separate overview. | Active alarm when Present value = binary "0". | ☐ |
| Present value on multistate objects is not used for alarm status, operating status or similar. | If so, consult Kiona to see if it is possible to transform the data in the IWMAC system. | ☐ |
| Binary data point for acknowledging/resetting alarms submitted. | The point should automatically return to resting position after activation. | ☐ |
| IWMAC top system calendars are used, linked to the following object: ___________________________ | Object type and ID or data point name for linking in substation, one per IWMAC top system calendar. Objects can be binary or multistate. If Kiona is to set the times, these must also be specified in advance. | ☐ |
| EDE and state texts submitted in CSV format. | See template: IWMAC TEMPLATE 04 – BACNET StateTexts.csv | ☐ |
| Large network with multiple subnets/IP ranges: topology submitted. | ☐ |
✅ 2.2 – IWMAC Checklist – Modbus
Modbus device scanning is not possible. Parameter lists in Excel must contain: register/address, data type (sint16, float, bool, uint32 etc.), bit number, start bit/count, word-swap/byte-swap, system+component+description, engineering unit, scaling, alarm priority A–B–C, status text (e.g. 0=Off 1=On), read/write flag.
| Checklist item | Explanation | Done (Yes/No) |
|---|---|---|
| Assessment of number of devices and update frequency on serial loops. | Kiona integrates full parameter list unless otherwise specified. | ☐ |
| Unique slave addresses and same communication settings per loop. | Baud rate, data and stop bits, parity. | ☐ |
| Device(s) fully commissioned and function-tested. | ☐ | |
| Register polling run to test contact with at least one register per device. | ☐ | |
| Bus topology with all devices sent. | Slave addresses, IP addresses, COM ports, media converters etc. | ☐ |
| Manufacturer, model and Modbus parameter list sent. | ☐ | |
| Complete Modbus parameter list prepared. | If equipment is custom programmable. | ☐ |
✅ 2.3 – IWMAC Checklist – N2 / N2 Open
Device scanning is not possible. Sufficient parameters for basic top-level system function (Operation/Fault/Frost/Calendar/Temperatures/Setpoint etc.). Per parameter: description (system+component+text), engineering unit, status text, read/write flag. Johnson DX: N2 protocol addresses required (e.g. AI1, XT3DI1, PM10K02). Johnson FX: .prn file insufficient; N2 addresses required (adf1, adi1, bd1, bit1).
| Checklist item | Explanation | Done (Yes/No) |
|---|---|---|
| Check the number of devices and refresh rate | An assessment has been made of the number of devices on serial loops to ensure the refresh rate for parameters will not be too low (should not take several minutes). | ☐ |
| Check addresses and communication setup | All serial devices on a loop have unique slave addresses and a similar communication setup in general. Baudrate, data bits and stop bits, parity. | ☐ |
| Device(s) commissioned and function-tested. | ☐ | |
| Bus topology with all devices sent. | ☐ | |
| Complete tag list prepared and sent to Kiona. | ☐ |
✅ 2.4 – IWMAC Checklist – KNX via NETxOPC server
For IWMAC to be able to integrate KNX, some information is needed to ensure everything functions as it should. It is not possible to “scan” the devices or data points from the devices, so the customer must export and transfer the necessary data from ETS (the programming tool).
Before the installation is programmed, a group address structure and naming must be submitted to IWMAC for review and approval, to ensure images can be linked effectively.
Before integration can be started, IWMAC must have received all the information specified in the checklist below. All parameters should be named in a way that makes them easily identifiable; see document “1 – Design and Integration Guide”.
An Excel file with supplementary information must contain the following 7 additional columns in addition to data from the *.esf file; see the bullets and extract below:
- Writeable parameters (rw)
- Unit of measurement (°C, m3/h, %, etc.)
- Scaling (0–255=0–100, etc.)
- Gateway/IP (to distinguish which parameters belong to which gateways)
- Alarm priority (A-B-C), A is the highest priority and will normally be sent by SMS to an alarm monitor
- Normally closed/NC (0=Alarm, 1=OK)
- Read on OPC boot (Read on reconnect)
If you receive Modbus documentation from the supplier, it is important that you check the documentation against the specification above.
The checklist below applies to all devices on a serial loop/upstream of a port on a media converter, or, where applicable, per unique device on Modbus TCP (IP).
The checklist below applies to the entire “integration”. In other words, the ETS database to which the integration applies. Therefore, the KNX installation must have been commissioned and tested in advance before IWMAC can import the parameter list.
| Checklist – KNX integration | Device:_____________________ | |
|---|---|---|
| Checkpoint | Explanation | Done (Yes/No) |
| Group address structure has been clarified and approved by IWMAC. | The structure is also adapted for efficient linking of room control images. | ☐ |
| All parameters are named in accordance with "1 – Design and Integration Guide", or, alternatively, have been discussed with and approved by IWMAC. | ☐ | |
| All components of the bus have been fully commissioned and function tested. | ☐ | |
| IWMAC has been notified of how many data points are to be integrated. | Licence for the number of data points and number of gateways. | ☐ |
| Topology showing each gateway with underlying bus lines and addresses. | ☐ | |
| Excel sheet with the necessary information in addition to the contents of the ESF file has been created and submitted to IWMAC. | ☐ | |
| *.esf file from ETS, cleaned of parameters that are not to be integrated, has been submitted to IWMAC. | Reconciled with the number of points specified at time of licence order. | ☐ |
| An overview of the desired SD calendars and which data points they should write to has been submitted to IWMAC. | Operating times must be known if IWMAC is to enter them. | ☐ |
✅ 2.5 – IWMAC Checklist – OPC DA
OPC device scanning is not possible. Challenging when OPC server is on another computer. Kiona needs to know if OPC server can be installed on IWMAC PC. Connection info needed: connection string, username/password, group address/access path, DCOM parameters (if on another PC), number of parallel threads. Parameter list: unique name+description (TFM+component), OPC address+data type+length, bit spec, engineering unit, scaling, status values (e.g. 0=Off 1=On), read/write flag (r/rw), alarm level (A/B/C).
| Value | Data type | Description |
|---|---|---|
| 0 | VT_EMPTY | Empty/Default |
| 2 | VT_I2 | 2-byte signed integer |
| 3 | VT_I4 | 4-byte signed integer |
| 4 | VT_R4 | 4-byte real |
| 5 | VT_R8 | 8-byte real |
| 11 | VT_BOOL | Boolean (TRUE=−1, FALSE=0) |
| 17 | VT_I1 | 1-byte signed integer |
| 18 | VT_UI1 | 1-byte unsigned integer |
| 19 | VT_UI2 | 2-byte unsigned integer |
| 20 | VT_UI4 | 4-byte unsigned integer |
| +8192 | VT_ARRAY | Array of values |
| Checklist item | Explanation | Done (Yes/No) |
|---|---|---|
| All parameters named per guide or approved by Kiona. | ☐ | |
| All components commissioned and function-tested. | ☐ | |
| OPC access tested with OPC client on IWMAC PC. | Confirmation that connection works. | ☐ |
| Connection information sent to Kiona. | ☐ | |
| Complete tag list prepared and sent. | ☐ | |
| Calendar overview sent. | ☐ |
✅ 3.1 – IWMAC Checklist – Ventilation
For Kiona to ensure correct IWMAC visualisation, we need adequate documentation. The goal is to create a simple, clear and understandable system for the end users of the installation.
The submitted documentation must as a minimum include: system number (e.g. 36.01, 360.01, 360.001) and description of operating area; installation-specific functional description including temperature control type (e.g. constant supply air temperature, outdoor compensated control), fan control type (e.g. constant airflow, constant pressure), active functions and setpoints (e.g. recirculation, night cooling, extended operation), seasonal compensation curves, calendar functions and interlocks; system diagram with component codes (as-built); and a decision on time control (automation clock or IWMAC top-level system calendar).
When using a top-level calendar the automation's internal clock must be deactivated. The checklist below applies per ventilation system (system number).
| Checklist – ventilation unit | System no.:_______ Device:__________ | |
|---|---|---|
| Checkpoint | Explanation | Done (Yes/No) |
| System diagram with all component codes has been sent to IWMAC, with "as built" component location | ☐ | |
| Codes on the system diagram are also in the parameter list | ☐ | |
| Alternatively, IWMAC labelling is used in images | ☐ | |
| IWMAC clock timer control is to be used | ☐ | |
| Alternatively, the regulator's internal clock timer is used | ☐ | |
| Functional description with information as requested above has been sent to IWMAC | ☐ | |
| Points on the checklist for the communication protocol have been dealt with | ☐ | |
| Any additional functions, such as weather forecast, power monitor, measured value distribution, alarm functions and similar, are set out in written supporting documentation | Remember to order smart functions if necessary. | ☐ |
✅ 3.2 – IWMAC Checklist – Heating and Cooling Systems
For IWMAC to be able to ensure the visualization we provide is correct, we need to receive adequate and accurate documentation. The aim is to create a simple, clear and understandable system for the end-user of the installation.
- Correct drawings (“as-built”) where the component labelling matches the labelling in the parameter list. I.e. automation that controls/regulates the heating system must have the same labelling as shown in the documentation.
- Complete parameter lists where the parameters have sensible and accurate texts and are labelled with component numbers according to the drawing. The end-user must be able to understand the texts – this is especially important for alarm texts.
- See “IWMAC Design and Integration Guide” for a detailed description of the requirements governing naming.
- Functional description of the installation. Everything relating to interlocks, alarm functions, seasonal switching functions and regulation functions must be included.
- Which set points does the customer want to be displayed directly in the screen image? (All parameters are available under Settings). In the image, we normally display important SPs that end-users must be able to modify, such as graphs, temperatures, setpoints, etc.
IWMAC designs images using its own standard that reflect the structure of the heating system in accordance with the PID drawing, as far as possible. IWMAC will make adjustments and subdivisions so that the result fits in with defined image sizes and symbols. All alarm indicators are entered as alarm bells; these are only visible in the event of an active alarm. IWMAC standard labelling is the Norwegian cross-disciplinary labelling system (TFM) to 3 digits. If an alternative is desired, this must be stated in the documentation. It is important that physical labelling matches the screen images visualized in IWMAC.
The checklist below applies to each heating or cooling system (system number).
Example of an image:
Example of a graph:
| Checklist – Heating and Cooling Systems | System no.:_______ Device:_________ | |
|---|---|---|
| Checkpoint | Explanation | Done (Yes/No) |
| System diagram with all component codes has been sent to IWMAC, with "as built" component location | ☐ | |
| Codes on the system diagram are also in the parameter list | ☐ | |
| Functional description with information as requested above has been sent to IWMAC | ☐ | |
| Points on the checklist for the communication protocol have been dealt with | ☐ | |
| Any additional functions, such as weather forecast, power monitor, measured value distribution, alarm functions and similar, are set out in written supporting documentation | Remember to order smart functions if necessary. | ☐ |
✅ 3.3 – IWMAC Checklist – Room Control
For IWMAC to be able to ensure the visualization we provide is correct, we need to receive adequate and accurate documentation. The aim is to create a simple, clear and understandable system for the end-user of the installation.
- To create the screen images, IWMAC must receive accurate floor plans of the building in dwg format, allowing the option of turning off the layers so that we are left only with the basic outline/room subdivision.
- An overview must be created of all rooms to be included in-room control, with the following specified:
- Room number/name
- Room type (if different room types)
- Regulator address
- The parameters to be visualized on the various room types. Our standard delivery includes visualization of up to 15 tags per room.|
See “IWMAC TEMPLATE 09 – Room list.xltx” for the desired layout of the overview of room types and tags to be submitted.
- Our standard procedure is to display room temperature and the current setpoint in pop-ups. Pop-ups will be adapted to the different room types we have received from the customer.
- Templates have been included for up to 10 different/individual room types.
- If the installation deviates from the standard procedure, this must be made clear at the time of sale, and specified accordingly.
- If the room control has been set up in a PLC etc., the room/parameter assignment must be clearly labelled, together with a readily comprehensible description of the parameters, see the document “1 – Design and Integration Guide”.
- The floor subdivision must take into account the desired number of parameters in the pop-up, the shape of the building and the logical division of the building stock used by the end-user.
- 1 time registry per floor is included – if a different subdivision is desired, this must be clarified with IWMAC.
- If visualization of override functions and smart functions is desired, this must be notified to IWMAC before the visualization work is commenced.
As far as possible, we create images according to our standard on the basis of dwg files sent to us. We make adjustments and subdivisions so that the result fits in with our image sizes and symbols.
An example of an image using standard symbols. If different symbols are required, this must be clarified in advance of the project:
| Checklist – Room Control | System no.:_______ Device:_________ | |
|---|---|---|
| Checkpoint | Explanation | Done (Yes/No) |
| A room list with room types and a list of all rooms of the various room types has been prepared and submitted to IWMAC | ☐ | |
| Clarification has been reached with IWMAC as to which values will appear in pop-ups | ☐ | |
| Floor plans have been submitted, in the format as outlined, and allowing easy removal of unwanted information | ☐ | |
| Submitted documentation contains all information requested in this document | ☐ | |
| Parameters have the same names as in parameter lists | ☐ | |
| Points on the checklist for the communication protocol have been dealt with | ☐ | |
| Any requests for visualization of override functions have been submitted (put a line through the box if not applicable) | ☐ | |
| Any additional functions, such as weather forecast, power monitor, measured value distribution, alarm functions and similar, are set out in written supporting documentation | Remember to order smart functions if necessary. | ☐ |
| Clarification has been reached with IWMAC as to the subdivision for time directories. Normally there is one time directory per floor | ☐ |
✅ 3.4 – IWMAC Checklist – Technical and Electrical
For IWMAC to be able to ensure the visualization we provide is correct, we need to receive adequate and accurate documentation. The aim is to create a simple, clear and understandable system for the end-user of the installation.
The signals are often spread across many substations, distributed throughout the building stock. This requires the customer to set down in a systematic way which signals are to be presented in the technical pages.
- IWMAC can group signals by location, system, discipline or signal type, as desired.
- Clarification is required as to how signals should be grouped.
- A table with complete tag ID and description of the objects must be created; see “IWMAC TEMPLATE 02 – Technical signals.xltx” for the presentation of supporting data.
- If there are limit values or other attributes that are relevant, these must also be included in the overview.
An example of an image using standard symbols. If different symbols are required, this must be clarified in advance of the project:
| Checklist – Technical and Electrical | System no.:_______ Device:_________ | |
|---|---|---|
| Checkpoint | Explanation | Done (Yes/No) |
| Customer has submitted a list of all technical signals to be presented in screen images | ☐ | |
| Customer has clarified with IWMAC how signals are to be grouped for presentation | ☐ | |
| Submitted documentation contains all information requested in this document | ☐ | |
| Parameters have the same names as in parameter lists | ☐ | |
| Points on the checklist for the communication protocol have been dealt with | ☐ | |
| Any additional functions, such as weather forecast, power monitor, measured value distribution, alarm functions and similar, are set out in written supporting documentation | Remember to order smart functions if necessary. | ☐ |
✅ 3.5 – IWMAC Checklist – Energy Report
When you order an energy module from IWMAC, you will have all energy meters entered in an energy report.
For IWMAC to be able to create a clear report, we need the customer to send us complete and accurate information about all the meters on the installation:
- All physical meters must have been implemented and commissioned on the installation.
- A quality assurance procedure must be undertaken, confirming that the physical meter and IWMAC show the same value.
- IWMAC must receive a list of the meters with labelling, plus an indication of the group in which the customer wants them presented; see document “1 – Design and Integration Guide”.
- It is also important to specify the device from which the measured value is to be taken (PLC, meter, district heating plant, etc). See “IWMAC TEMPLATE 01 – Energy report.xltx”.
A standard grouping is offered:
- Energy – Electric
- Energy – Thermal Heat
- Energy – Thermal Cooling
- Water Meters – Volume
In an energy report, the meters are entered 1 to 1 and no calculations are offered in this setup. If calculations are required, this setup must be upgraded to an energy monitoring system (EOS), where a more advanced and building-specific setup is offered.
| Checklist – Energy Report | System:_________________ | |
|---|---|---|
| Checkpoint | Explanation | Done (Yes/No) |
| Meter structure submitted to IWMAC | ☐ | |
| Measured values on all meters have been checked and approved | ☐ |
✅ 3.6 – IWMAC Checklist – EOS (Energy Monitoring System)
For IWMAC to be able to set up a clear and accurate EOS, we need to have a good picture of how the customer wants to visualize the energy setup.
- All physical meters must have been implemented and commissioned on the installation.
- A quality assurance procedure must be undertaken, confirming that the physical meter and IWMAC show the same value.
- A decision must be made on how to group the tree structure and which calculations are required.
- IWMAC must receive a list of the meters with labelling, plus an indication of the group in which the customer wants them presented. See document “1 – Design and Integration Guide”.
- It is also important to specify the device from which the measured value is to be taken (PLC, meter, district heating plant, etc). See “IWMAC TEMPLATE 06 – EOS.xltx”.
When selecting multiple meters/groups of meters in EOS, the main point to note is that all parameters specified under these will be totalled in the system (Energy/Volume/Persons/Area).
A clear strategy is therefore needed on how to group meters and at what level in the system persons/area should be specified in order to avoid these being totalled multiple times in the same group.
This requires that the customer decides how they wish to use the system and what data they want to extract at the different levels. The structure should then be planned on this basis.
For us to be able to present an energy/temperature graph, there must be an outdoor temperature we can use for this.
Example of a tree structure:
| Checklist – EOS | ||
|---|---|---|
| Checkpoint | Explanation | Done (Yes/No) |
| All calculations to be made have been documented and submitted to IWMAC | ☐ | |
| All key indicators have been submitted to IWMAC | Persons per area, area for each building part, etc. See EOS template | ☐ |
| Clarification has been reached with IWMAC as to which reports can be extracted | ☐ | |
| Meter structure submitted to IWMAC | ☐ | |
| Measured values on all meters have been checked and approved | ☐ |
Templates:
📊 IWMAC Template 01 – Energy Report
Select tab: EN – Energy Report.
| Main group | Meter name | Located on device | Comment |
|---|---|---|---|
| Electrical Energy | |||
| 001.001-OE01-[Name] | 001.001-OE01 | ||
| Thermal Energy – Heating | |||
| 011.001-OE01-[Name] | PLS01 | ||
| Thermal Energy – Cooling | |||
| 021.001-OE01-[Name] | PLS01 | ||
| Water Meter – Volume | |||
| 031.001-OE01-[Name] | 031.001-OE01 |
📊 IWMAC Template 02 – Technical Signals
Select tab: EN – Technical Signals.
| Main group | Component as in tag list | Located on device | Comment |
|---|---|---|---|
| 310 Sanitary | |||
| 310.001-MO001 | 434.002-OU001 | ||
| 351 Cooling | |||
| 351.001-QS001 | PLS1 |
📊 IWMAC Template 03 – BACnet EDE
The BACnet EDE file (Engineering Data Exchange) is the standardised CSV format used to export BACnet object lists from a substation and import them into IWMAC. Kiona has added four extra columns at the end of the standard format.
| Column | Type | Description |
|---|---|---|
| keyname | Standard | Unique object name (e.g. OBJECT_ANALOG_INPUT:11164) |
| device obj.-instance | Standard | Device instance number |
| object-name | Standard | Short object name (e.g. RT401 SUPPLY TEMP) |
| object-type | Standard | Object type (0=Analog Input, 1=Analog Output, 3=Analog Value, 4=Binary Input etc.) |
| object-instance | Standard | Object instance |
| description | Standard | Description – must contain system number + component code + text (e.g. "360.001 RT401 Supply air temperature") |
| settable | Standard | Y = writable in IWMAC, N = read-only |
| state-text-reference | Standard | Reference number to Template 04 StateTexts (for binary/multistate objects) |
| Alarm Pri | Kiona addition | Alarm priority: A (highest/SMS), B or C |
| Include Attri. | Kiona addition | 1 = include attributes (e.g. intrinsic reporting). Requires a separate attribute list. |
| Gruppe | Kiona addition | System number for grouping (same for all objects in the same system) |
| Rom | Kiona addition | Room designation for room control objects (same for all objects in the same room/zone) |
Tip: Open the CSV file in Excel using semicolon as delimiter. Always save as CSV UTF-8 without BOM when sending to Kiona.
📊 IWMAC Template 04 – BACnet StateTexts
The StateTexts file defines text labels for BACnet objects with integer or binary values. It is referenced from the EDE file via the state-text-reference column. Each reference number (1, 2, 3…) defines a set of texts where text 1 = value 0, text 2 = value 1 etc.
| #Ref | Text 1 (value 0) | Text 2 (value 1) | Text 3 | Text 4 |
|---|---|---|---|---|
| 1 | OK | Fault | ||
| 2 | SD clock | FAC clock | ||
| 3 | Off | On | ||
| 4 | Winter | Summer | ||
| 7 | Auto | Off | On | |
| 8 | Low | High | Auto (outdoor temp) |
Tip: Add your own rows for each unique state combination in your installation. The reference number links to the state-text-reference column in the EDE file. Binary objects need at least 2 texts (e.g. Off/On). Multistate objects can have up to n texts.
📊 IWMAC Template 05 – DX9100
Template for Johnson DX9100 controllers. Edit Template 1 or Template 2. The Example tab shows sample data and Element IDs contains all DX9100 element ID references.
| Column | Description |
|---|---|
| Element_id | N2 protocol address, e.g. PM01K01, AI1 |
| System number | TFM system number, e.g. 360.001 |
| Tag text | Component code/tag, e.g. RT401 |
| Aliastext | Descriptive name of the parameter |
| Alarm | Alarm level: A (highest/SMS), B or C |
| Eng unit | Engineering unit, e.g. °C, %, m³/h |
| Scale | Scaling, e.g. x100 or x10 |
📊 IWMAC Template 06 – EOS
Template for energy monitoring system (EOS). Select the EN – EOS tab. The template has 8 columns:
Main group → Sub-group 1 → Sub-group 2 → Sub-group 3 → Sub-group 4 → Located behind meter → Physical meter → Virtual meter (col. M)
| Main group | Sub-group 1 | Sub-group 2 | Sub-group 3 | Sub-group 4 | Located behind meter | Physical meter | Virtual meter (col. M) |
|---|---|---|---|---|---|---|---|
| Outdoor temperature | |||||||
| Block A | |||||||
| Thermal meters | |||||||
| Heating system | 300.001-OE01 | ||||||
| Ventilation | 310.001-OE02 |
Tip: Sub-groups 3 and 4 are used for deeper hierarchies. "Located behind meter" indicates which sub-levels are summed in a parent meter. Column M (Virtual meter) describes calculated values without a physical meter.
📊 IWMAC Template 07 – FX15
Template for Johnson FX controllers. Edit the Parameterliste sheet (original). The Status EN tab (Statustekster) contains status texts in English, Guide EN explains the columns.
| Reference | 0 | 1 | 2 |
|---|---|---|---|
| AvPå | Off | On | |
| AutoAvPå | Auto | Off | On |
| NormalAlarm | Normal | Alarm | |
| NormalFeil | Normal | Fault | |
| InaktivAktiv | Inactive | Active | |
| AapenLukket | Closed | Open | |
| AutoNatt | Auto | Night | |
| NormalUtløst | Normal | Triggered |
Key columns:
| Column | Description |
|---|---|
| Point type | ADI=integer, ADF=float, BD=boolean |
| Point address | N2 address, e.g. adf1, adi1, bd1 |
| Direction | Input=read-only, Output=writable |
| Long name | Full descriptive name |
| Alarmnivå | A (highest/SMS), B or C |
| rw-flagg | r=read, rw=read/write |
📊 IWMAC Template 08 – Modbus
Modbus – in English for all languages.
| Column | Description |
|---|---|
| Section A – System code | System number/TFM code |
| Section B – Component code | Component and function code |
| Section C – Description | Descriptive text |
| Data type | BOOL, UINT16, INT16, FLOAT32 etc. |
| Function code (read) | Modbus read FC (01,02,03,04) |
| Function code (write) | Modbus write FC (05,06,15,16) |
| Register type | 0x coil/1x input/3x input reg/4x holding reg |
| Register address | Modbus register address (decimal) |
| Engineering unit | e.g. °C, %, m³/h |
| Scale (reference) | Scaling from Scale tab |
| State-text (reference) | Status text from State-Texts tab |
| Alarm level | A=highest/SMS, B, C |
State-Texts tab:
| Reference | 0 | 1 | 2 |
|---|---|---|---|
| OnOff | Off | On | |
| AutoOffOn | Auto | Off | On |
| NormalAlarm | Normal | Alarm | |
| NormalFault | Normal | Fault |
📊 IWMAC Template 09 – Room List
Select tabs: EN – Room types and EN – Building x wing x.
| Room type | Description | Temperature (RTxxx) | CO2 (Ryxxx) | Humidity (RHxxx) | PIR (RBxxx) |
|---|---|---|---|---|---|
| RoomType1 | [Room] | °C / r | ppm / r | %RH / r | r |
| RoomType2 | [Conference] | °C / r | ppm / r |
📊 IWMAC Template 10 – Simple Topology (IP only)
IP-only topology. Select the EN – Topology IP only tab.
| Equipment | Location/floor/room | Switch/room/floor | IP address | Mask | Default gateway | DNS1 | Port |
|---|---|---|---|---|---|---|---|
| =360.001 | Floors 2–9 | Switch-A | 10.0.12.3 | 255.255.255.0 | 10.0.12.1 | 8.8.8.8 | |
| =432.001 | Energy centre | Switch-A | 10.0.12.5 | 255.255.255.0 | 10.0.12.1 |
📊 IWMAC Template 11 – Topology IP + Serial Converters
IP topology with serial converters. Select the EN – Topology IP + serial tab.
| Equipment | IP addresses | Subnet mask | Serves | IP driver | Driver address |
|---|---|---|---|---|---|
| Block A | |||||
| =360.001 | 10.0.12.3 | 255.255.255.0 | Floors 2–9 | PMGOLDA | 1_1 |
| Sauter | 10.0.12.5 | 255.255.255.0 | Energy centre | BACnet | 0_1 |
| Moxa | 10.0.12.6 | 255.255.255.0 | Modbus serial |
📊 IWMAC Template 12 – Topology Example
Exported PNG image of the topology diagram. Shows the network topology with all automation devices, IP addresses, switch, firewall and Kiona server. Used as a reference image in documentation and as an attachment.
📊 IWMAC Template 13 – Topology Source (Gliffy)
Version 1.0 – April 2026
-
SUOMI_IWMAC_Tarkistuslistat_ja_Mallit.zip
2 MB Download
-
DANSK_IWMAC_Tjeklister_og_Skabeloner.zip
2 MB Download
-
DEUTSCH_IWMAC_Checklisten_und_Vorlagen.zip
2 MB Download
-
ITALIANO_IWMAC_Liste_di_Controllo_e_Modelli.zip
2 MB Download
-
POLSKI_IWMAC_Listy_Kontrolne_i_Szablony.zip
2 MB Download
-
NORSK_IWMAC_Sjekklister_og_Maler.zip
2 MB Download
-
FRANCAIS_IWMAC_Listes_de_Controle_et_Modeles.zip
2 MB Download
-
SVENSKA_IWMAC_Checklistor_och_Mallar.zip
2 MB Download
-
ENGLISH_IWMAC_Checklists_and_Templates.zip
2 MB Download