Visualisation Systems. KNX Association

Transcription

1 Visualisation Systems

2 Table of Contents 1 Visualisation systems General Requirements for a Central Display Terms The term visualisation : The term Datapoint The term Process point Static Images Dynamic Image Elements (Variables) Transfer of the KNX Project Design Data Notes for Recording the Status with the Visualisation Notes for Starting the Visualisation Connection of the Visualisation to the Bus System Direct connection via hardware interface Indirect connection via gateway (Hardware) or server (Software, e.g. OPC server) Direct access to a KNXnet/IP-Server Exporting project data: Support by ETS Physical access point in the Bus System Telegrams sent across Lines/Areas Enabling the Filter Table Correcting the Filter Table via Dummy Devices Types of Bus Communication Program start up: Normal operation condition Data Recording Modes Summary of Bus Access Types of visualisation Introduction KNX device with embedded visualisation software Mobile device with external visualisation software installed Client/Server based visualisation Visualisation Systems Visualisation Systems_E1212a 2/26

3 1 Visualisation systems 1.1 General A KNX installation has a distributed structure, in which all devices communicate with each other when required. It is not necessary to control them centrally. Nevertheless, the technology allows establishing control stations that can represent functions in graphical format, both as remote operating as well as display elements. Figure 1: Example of an installation with various input - and output variables Visualisation Systems Visualisation Systems_E1212a 3/26

4 1.2 Requirements for a Central Display The operator would like to be able to detect from a central location whether e.g.: Lights are still switched on somewhere in the installation, although they should already be turned off, Blinds remain closed somewhere in the installation, although they should already have been retracted, Windows or doors remain open, which may cause security risks; So generally said: The operator would like to have collective status messages of certain groups of functions or devices He would further like to know the exact location (building/floor/room) where the light is still switched on and would like to be able to switch it off from a central location. When monitoring building services systems, the operator would like to Be aware of any alarms or faults see images of integrated video cameras see the current status of consumption or view metering statistics know the location in the building of a displayed fault know when the defect occurred Beyond these requirements more and more users demand to have the operational data displayed independent from hard- / software platforms (e.g. Type of PC and OS). If this is ensured, service providers can take over the buildings management s tasks for cost optimization sake and don t have to be onsite all the time. Platform independence however also means that the original data have to be available in a format that allows various communication channels and pc-environments to be used. 1.3 Terms The term visualisation : Visualisation is the representation of states (observation) and the selection of states (operation). In building automation technology, this is generally understood to be a software package, in which parameters can be assigned relatively easily and can be implemented on a mini computer. The term mini computer covers PCs, CPUs that have been prepared for this special task, but also mobile platforms which are mostly used in mobile phones and tablets. In the widest sense, you can also designate miniature panels as depicted here as visualisation terminals. Many of the statements made here however also apply to the operation of panel units. Figure 2: Visualisation terminal and mobile phone as display and operation means for KNX Visualisation Systems Visualisation Systems_E1212a 4/26

5 1.3.2 The term Datapoint The format of information that is to be displayed (=Datapoint type in ETS) is determined by the datapoint. That does not only include the value of a function, but comprises also its further interpretation. E.g. a 2-Byte value, which originally is just a hexadecimal figure, could be an unsigned integer, a signed integer, or a floating point value. Moreover, units can be declared (like Lux, C, L, etc.), or so called status texts (mainly used for binaries, like On, Off instead of 1 / 0), which describe the value better for the user. So a datapoint is a template, which is put on a value to make it readable in a display or a monitor. It describes a class of different values with a common format The term Process point The process point is the interface between the information for display/selection and their graphical representation on the screen, i.e. the display type of a certain value. The term process point unfortunately is not well-known most people always use datapoint and mean process point. This is however not very practicable, as this may give rise to confusion as one loses one definition layer, which ensures a better category assignment of the data. A process point is based on a certain datapoint type. It however adds important information that should not be neglected for proper display and use: Which group address carries the information? (There can be more than one: in case a bus device doesn t have a status object, all group addresses assigned to e.g. a switching object must also be known to the process point to always display the correct status). Is a value only used for display, or also for control? ( Transmit Flag ). Which user level may have access for read only, or for read / write? (= Lights should be switchable and not only displayed) Which additional tasks have to be carried out with the values of this process point? (Save data cyclically in a value data base, create event messages, alarms, start another display page on a certain condition, mandatory confirmation of an alarm, etc.) Static Images As a visual aid for the user of the visualisation program, static background images can be created or imported which e.g. show the ground plan of the visualised area or enable a 3D representation of the room. Current states cannot be indicated using a static background image. Visualisation Systems Visualisation Systems_E1212a 5/26

6 1.3.5 Dynamic Image Elements (Variables) Using dynamic image elements or variables, the required information/states can be displayed on the screen. Figure 3: Appearance possibilities of image variables The appearance of an image variable is modified depending on the process state (shape, colour, text, flashing, etc.). Switching and positioning commands can be preselected on the bus. A range of predefined types of variables are available for selection. The individual types can be freely positioned on the screen and overlay part of the static background image. The appearance, colour, function etc. are set via parameters. The size can be changed in the usual way by dragging the image. A process point must be assigned to each variable, which is allocated from the list of process points using drag and drop. Simple visualisation packages don t provide datapoints or process points as separate items, but include it all in the image variables. In this situation it is quite easy and quick for the user to assign group addresses, activate the switchable function (=activate send flag ), set up the display format, units etc, but since this needs to be done from scratch again and again, it is only acceptable in smaller projects, not in large ones. The characteristics of high performance visualisation software packages include: one central or several networked visualisation/operator terminals the generation and parameterisation of the process points for display, the reading in of images as pixel or vector graphics, an integrated image editor for vector graphics with a macro library, various dynamic picture elements (variables) for the display of current states, values, information, the printing of event, overview and parameter logs as well as colour screenshots, display, operation and logging, in several languages powerful additional functions such as statistical functions, Internet ADSL, ISDN connections, event and timer programs. Visualisation Systems Visualisation Systems_E1212a 6/26

7 Figure 4: Screen image from an industrial application: various, freely selectable, graphical and numerical representations of the same process point. The data in the lower graphic can also be recorded and evaluated over longer periods Figure 5: Picture from a home application: user-friendly, clear layout with freely configurable operator and display functions Visualisation Systems Visualisation Systems_E1212a 7/26

8 1.4 Transfer of the KNX Project Design Data The assignment of group addresses to sensors and actuators is carried out when designing an installation using the KNX Engineering Tool Software (ETS). The data that has been configured in ETS can in many cases be directly transferred to the visualisation program. The following data is transferred: Existing bus devices and their comments Existing objects and their settings Configured group addresses and their comments A further possibility of transferring the functionality of the bus devices is to read out the existing bus devices directly from the bus system. You will, however, only receive the numerical structure of the addresses and their data field width and no text descriptions. The group addresses can also always be entered manually, if no data interface between ETS and the software exists. Visualisation Structured Project D i Einheitstexte Unit text Zustandstexte Status text Hinweistexte Notes EIS-Typ DPT type Datenpunkt Datapoint Eigenschaften Properties Group Gruppenadressen addresses Prozeßpunkt Process point Flankenauswertung Edge evaluation Image Bildvariablen variables Figure 6: Structured Project Design 1.5 Notes for Recording the Status with the Visualisation The states that should be recorded in a KNX installation are detected by the visualisation by listening into the bus telegrams. In some bus devices, it is possible however to carry out a switching operation not directly with a telegram, but to start periods that trigger switching operations with a delay or via a logic operation with other states. This means that the telegram cannot be used in these cases as a status image. In specific applications, additional status objects are therefore available in which the current switching state is mirrored. If these objects do not transmit by themselves, they must be read out cyclically by the visualisation software via read requests. Note: The read flag must be set in the status object, so that the bus device responds to the read request. Visualisation Systems Visualisation Systems_E1212a 8/26

9 1.6 Notes for Starting the Visualisation As already mentioned above, the visualisation receives its information during operation from the bus devices by listening to the relevant telegrams on the bus. After a restart of the visualisation program e.g. after a voltage breakdown, it must query the current states of the bus devices, as they are only updated in the visualisation after a corresponding telegram on the bus. This interrogation of the states is carried out automatically once the visualisation is started up, i.e. the states of all bus devices are read out one after the other. To do so, the read flag must however be set in the corresponding object of the bus device and the group address entered in the process point must be defined as a sending group address in the object. This address thereby becomes readable and the visualisation knows which object must be read out in which bus device, when updating the process point. Several group addresses can be linked in a process point similar to a device object. It now depends on the correct setting of the process point, whether it will be initialised correctly after start-up. It can be problematic if several group addresses are set as readable and indicate a different state. This means that the process point always accepts the status of the last group address in the process point that was allocated as readable using the equivalence -processing rule. In the event of a logic operation, the result of the OR or AND function is indicated via all readable groups which may not always be correct. A central address or an address that is used by several bus devices may never be implemented as a sending group address in the objects of the bus devices. The response telegram as the result of a read request will be interpreted as a normal write telegram, at least by all affected mask 1.x bus couplers. So the response telegram, using by coincidence a central function group address, will switch lights or move blinds although this was never intended to! In other bus coupler types this can be avoided by deactivating the Update-Flag. 1.7 Connection of the Visualisation to the Bus System The device on which the visualisation program is installed can be connected to the KNX system in various ways Direct connection via hardware interface In small or medium sized systems even today a direct interface is preferred, especially for stand-alone KNX systems without any data interfaces towards e.g. an upper building control system. In order to perform that type of coupling, just a data interface must be used supported by the visualisation package in question. This may be today RS 232, FT 1.2, USB, UDP/IP or TCP/IP protocol based interfaces. Visualisation Systems Visualisation Systems_E1212a 9/26

10 1.7.2 Indirect connection via gateway (Hardware) or server (Software, e.g. OPC server) Large installations usually run through a superior building management or - control system (BMS). On the field level, several different buses may exist. The BMS should thus collect the data of all these independent partial systems. Two possible solutions are known today: Connection via gateway In this case the visualisation will still be connected directly (by hardware) to the BMS. The BMS on the other hand uses protocol converters (Gateways) to read or control data from / to the underlying field level systems Connection via OPC server In OPC in contrast to direct connection each bus segment provides the necessary data on a server. The format of the data follows the definitions of the OPC foundation (OPC = Object linking and embedding for process control). So there are as many OPC servers as bus systems in one installation. The BMS however draws a big advantage from the fact that all data exist in the same format on OPC servers! In this way a parallel access to all these different servers via the local data network is possible, which is usually Ethernet communication (TCP/IP or UDP/IP). The OPC server itself is nothing else than a software for data transfer, intermediate saving (buffering the process image) and if necessary conversion. The OPC specification also requires that an OPC server is multi client capable, i.e. it can be accessed simultaneously by multiple monitoring stations. The OPC server can run on any standard PC (but should better be implemented on a real server workstation, due to higher endurance quality), but it can also be implemented (embedded) in specific hardware. Even an OPC server after all needs to have a direct data access point to the bus. This again can be one of the kinds already stated above in (direct connection). An embedded OPC server combines hardware interface and server software, and offers the advantage of a higher reliability compared to a PC, consuming less power, as having no moving mechanical parts, and serving for only one single task, the risk of a crash is negligible. The advantage of an OPC server in general is that the process image of the bus installation is stored in its memory, and is always up to date, even, if the monitoring system of the BMS is temporarily out of service. The restart of the monitoring system will be much faster compared to a direct bus access at a speed of not more than 9,6 Kbit/s. Visualisation Systems Visualisation Systems_E1212a 10/26

11 Figure 7: OPC server operation concept Direct access to a KNXnet/IP-Server With the introduction of the KNXnet/IP specification, there is also the possibility of location independent KNX network access via Ethernet. In this case the access point to the KNX network is a KNXnet/IP capable device, e.g. a so called IP router. Three core services are defined to connect a KNXnet/IP visualisation to the bus: a) Routing service b) Tunnelling service c) Object service These services distinguish themselves as follows: - Routing is comparable to a line coupler s function, transferred to Ethernet. The group address filter tables of the IP Routers are activated, and determine the data exchange between the KNX-TP1 (bus) side and the LAN. On the LAN level all IP routers and also the visualisation servers communicate via a common so called IP multicast address. Its notation reads like all other IP addresses. The address is worldwide published and standardized as the default KNX-Multicast address. That means, this address is basically blocked in all LAN routers worldwide, in order to avoid unintended broadcasting of KNX. As long as all members of the same shared multicast address remain in the same IP subnetwork, they will simultaneously read all messages (=datagrams), like line couplers do it from the main or area line. Advantage of the routing service: The server can act like another IP router in the network, it can send datagram without special dedication, because they are filtered as appropriate by the IP routers. Disadvantage: The data load on Ethernet is higher, because the datagrams must be forwarded to all IP routers of the same group. - Tunnelling is the direct access to an IP gateway (or router). In this mode filter tables are ignored; the bus telegrams are literally tunnelled through the filter table of the router. The advantage: you can use all group addresses, even, if the filter tables have not been set up correctly. The data load on Ethernet is less than with routing. Disadvantage: Only one line can be accessed by a single UDP datagram from the server. Visualisation Systems Visualisation Systems_E1212a 11/26

12 - Object server mode means that the IP visualisation server is connected to an application device with normal bus communication objects, which also has a LAN connection on the other side. One could call it routing plus tunnelling at the same time, because only the specific group addresses used by the device will work in both directions Example: IP-Visualisation via IP-Process-Server Figure 8: Configuration manager of an IP visualisation: Here all three core services can be used simultaneously Figure 9: Configuration tool of a simple table style web based monitoring and operation software Visualisation Systems Visualisation Systems_E1212a 12/26

13 Figure 10: The result when activating the configuration shown in the previous picture. A platform independent web page which can be operated under any standard web browser 1.8 Exporting project data: Support by ETS To get the necessary group address data from ETS into the visualisation, a special data export function is provided by ETS. Only group addreses are not sufficient information you ll need also the information about the assigned datapoint format (the DPT s, mentioned in 1.3.2). In addition to this minimum information it is recommended to have knowledge about the active communication flags of the objects assigned to the group addresses. Only with that knowledge a visualisation can decide immediately which datapoints are readable, and which are not (e.g. for cyclic update services). Presently ETS doesn t export these additional data. Figure 11: OPC data export file from ETS Visualisation Systems Visualisation Systems_E1212a 13/26

14 The following table is exported by this function: Visualisation Systems Visualisation Systems_E1212a 14/26

15 1.9 Physical access point in the Bus System In principle, the visualisation can be connected at any point in the bus system, no matter what type of coupling is chosen (OPC, KNXnet/IP or direct). To achieve good bus dynamics, particularly in larger bus systems, it might however be worth considering the underneath suggested access point places. If the bus system only consists of a line, the visualisation can of course only be connected here. If the bus system consists of several lines, it is advisable to connect the visualisation to the main line, to enable optimum access to all lines: Main line EDI LC 1 LC n Visualisation DVC 1 DVC 1 DVC 64 DVC 64 1 < n < 16 Line 1 Line n Figure 12: Optimal physical access point when there is one area with several lines EDI: Electronic data interface; e.g. USB If several areas are used, the visualisation is best connected to the backbone line. It is thus guaranteed that the information from the various areas and lines can reach the visualisation using the shortest route. Backbone line EDI BC 1 Visualisation Main line LC 1 LC n DVC 1 DVC 1 1 < n < 16 Line 1 DVC 64 DVC 64 Line n BC LC DVC = Backbone coupler = Line coupler = Bus device Figure 13: Optimal physical access point when there are several areas EDI: Electronic data interface; e.g. USB Visualisation Systems Visualisation Systems_E1212a 15/26

16 1.10 Telegrams sent across Lines/Areas If information across lines or areas should be processed by the visualisation or if commands from the visualisation are sent on other lines or areas, the behaviour of the coupler must be taken into account: Each line/backbone coupler has a filter table which contains the information as to whether a global telegram is required in its line (area) or whether a local telegram is also required outside its line (area). This filter table is created by the ETS program in the course of the project design. The visualisation is however not taken into account by ETS and this information is therefore omitted. But a visualisation can be regarded as a very complex bus device using plenty of group addresses. There are therefore two different options for preparing the couplers for use with a visualisation: Enabling the Filter Table The behaviour of the filter table is set separately per direction for each coupler via the parameter list: Direction of primary line secondary line: Block (no telegrams are routed) Enable (all telegrams are routed) Normal (filter table decides whether telegrams are routed) The first step is to consider in detail the route of each telegram to be visualized or sent by the visualisation to the bus devices. Using ETS, the filter table should then be enabled in the relevant coupler for the corresponding direction and the program should be reloaded. By enabling the filter table, all the telegrams are routed in the appropriate direction. This will have a negative influence on the bus dynamics in larger installations, primarily, if a large number of central functions and control systems have been configured. This possibility is only available in installations where the enabling of the filter tables does not lead to the overloading of individual lines. As the determination of the actual bus load in enabled filter tables can only be carried out manually and is very time-consuming, the filter tables should generally be used. Visualisation Systems Visualisation Systems_E1212a 16/26

17 Correcting the Filter Table via Dummy Devices To ensure that the ETS program takes into consideration the group addresses used by a the visualisation when creating the filter table, dummy devices can be configured in the line where the visualisation accesses the bus. All group addresses shall be entered in these devices, which the visualisation listens to or sends. Specially developed applications are available as dummy devices, which are part of several manufacturer product databases. These dummy devices have the advantage that they offer objects of all common sizes and allow to link up to 500 group in one dummy. Only the communication flag and the write flag may be set for the objects as otherwise in case of automated data transfer from ETS to visualisation - the visualization may later attempt to access such groups, although not really physically existing in the line in which the visualization is installed. Figure 14: Parameters and objects of a dummy application After extending the project by dummy devices using ETS, the filter tables of all affected couplers must be reloaded. Visualisation Systems Visualisation Systems_E1212a 17/26

18 Dummy devices are only used to take into account the visualisation settings when creating the filter table. These devices do not need to and cannot be put into operation. If none of above described options is implemented, telegrams that are required by the visualisation for status display may not be routed to the line, in which the visualisation is installed or a command telegram may not be routed to the line, in which the target actuator is located Types of Bus Communication Program start up: When starting the program, basically all groups should be read out, including those which are not set as readable. It thus depends on the quality of the ETS project, whether the images and information display works correctly. Read flags may be set only once per group address, only in this case it is guaranteed, that the read telegrams will trigger exactly one response telegram upon start up. In general, the status objects shall be connected to the visualisation, as they are the only objects always guaranteeing a correct display. Switch or value objects can send wrong values, depending on the parameter settings. Visualisation Reading out the status read flag L Luminaire group 1 L Luminaire group 2 L Read Leseflag flag 1/1 (0/1) Read Leseflag 1/1 (0/1) Read Leseflag flag 1/2 (0/1) 1/1 1/1 Read request to 1/1 Response telegram to 1/1 (sending group address) Important: A central group address may never be set as sending Figure 15: General strategy to read status information Normal operation condition During the normal operation period, the process image is stable, and only few changes take effect now and then. It is now important to verify such process point changes immediately. Three strategies are possible in this situation: a) permanently listening into the bus: all display relevant telegrams are also routed to the visualisation. b) Read back after transmitting: a sent telegram is verified as soon as it is sent, by the visualisation sending a read telegram to collect the new status of the controlled channel (a method which becomes more and more obsolete with automatic responding status objects) Visualisation Systems Visualisation Systems_E1212a 18/26

19 Visualisation Reading back after sending Actuator USB Read flag 1/0 (0/1) Time Source addr. Target addr. Type Switch command to group 1/0 2. Open up communication with actuator " " 3. Read request to: Memory location "Object status" 5 4. Reply to the read request with the object status 5. End communication Figure 16: Behaviour in transient condition: specific process points are checked for their actual state once a telegram is sent, if the status is not reported automatically c) cyclic read back: this method to keep status information as up to date as possible is only used, if either the status objects do not report automatically their status or an automatic status transmission on change would lead to an unacceptable high busload. Examples for such kind of devices are operational hours counters. They usually count in a second s resolution. If they would send a telegram on each value change, the bus data capacity would be used up literally in a minute! To avoid this, the visualisation can do a cyclical update of these values, e.g. every 120 seconds. 4 3 Visualisation Reading out cyclically S/D actuator USB Read flag 1/13 (0/1) Time Source addr. Target addr. Type Read request to group 1/13 2. Reply to group 1/13 Figure 17: Specific picture elements are updated at defined intervals Visualisation Systems Visualisation Systems_E1212a 19/26

20 Data Recording Modes Visualisations are not only used for current operations such as display changes and operate functions, but mainly for data tracking. The operator later can in this way analyse very verbosely what the user behaviour was, the consumption of resources versus users, and many more things (Operation statistics). It is also possible to draw decisions on the maintenance activities and schedules. Visualisation Event logging Process Prozeßpunkt point Status Printer EXCEL Historical database Event database EXCEL Export Export Trends Statistics Figure 18: The events that are to be logged can be stored in various databases and evaluated at a later date. A direct online output can be carried out on the logging printer Summary of Bus Access Visualisation Bus access USB Actuator Read flag 1/1 (0/1) Readable 1/1 - Start-up - Read back - Status appl. } Read Write Listen Response Mirror Process Prozeßpunkt point 1/1 (0/1) Status Ausgabe- Output variable Anzeige- Display variable Figure 19: Summarized graphic showing all possible communication modes between a visualisation and the bus devices Visualisation Systems Visualisation Systems_E1212a 20/26

21 1.12 Types of visualisation Introduction There are three different types of KNX visualisation. These are the following: KNX device with embedded visualisation software, e.g. a touch panel with an embedded KNX BCU, therefore configurable either via ETS directly, via an ETS plugin or even by using an external configuration tool. Mobile device, such as a smartphone or a tablet, which has the visualisation software installed on it. Usually the connection to the bus is achieved via WiFi using a KNXnet/IP router, connected with a common Ethernet/WiFi access point. As any device that has a WiFi transceiver can use this type of visualisation, this type of visualisation is very flexible and easy to use. Client/Server based visualisation, where the visualisation software runs on a central device as server and can be accessed by other devices as clients. A client can either be a touch panel, a television set, a computer, or ever a mobile device, such as a smart phone or a tablet KNX device with embedded visualisation software Description of a KNX device with embedded visualisation Compared to only a few years ago where they only had limited functionality, a KNX device can nowadays be very powerful and integrate rich graphics on displays and touch panels. Such a device is usually a display unit or touch panel, with an embedded KNX controller, to connect to the bus and monitor and control elements on a KNX installation. Moreover, even more powerful visualisation devices may even have an Ethernet adapter allowing connection to a broadband network and accessing even more services or devices Finding a KNX device with embedded visualization Many manufacturers today at least have one solution for visualising an installation in their KNX portfolio. Usually they can be found in catalogues under the section touch panels, displays, room controllers, signalling, or similar. Figure 20 KNX devices with embedded visualization Visualisation Systems Visualisation Systems_E1212a 21/26

22 Configuring a KNX device with embedded visualisation KNX S-mode devices are configured and commissioned with ETS on the basis of a product database file (vdx or knxprod): this data of the desired visualisation device needs to be imported in ETS. It has to be configured either directly via the Parameters dialog or via an ETS plug-in. Moreover, the user shall assign the group addresses to the respective communication objects. Subsequently, the device has to be commissioned and obtain its physical address. Figure 21 Configuration of a KNX touch panel in ETS Figure 22 The result on the device after commissioning Visualisation Systems Visualisation Systems_E1212a 22/26

23 Figure 23 Configuration of a KNX touch panel using an ETS plug-in and the result after commisioning Mobile device with external visualisation software installed Description of a mobile device with external visualisation software installed Mobile devices, such as mobile phones (also called smartphones ) and tablets have become important instruments in our daily life and are used for many purposes, e.g. entertainment, business activities, navigation,. There are different types on the market, most of them equipped with a WiFi transceiver and running specific operating systems, in which users are allowed to install external software (usually called App ). Therefore, visualisation software mostly takes the form of an App, installable on such devices, performing visualisation operations. The visualisation of a KNX installation in a mobile device can be realized by installing and configuring the visualisation App in the desired device and getting access via its WiFi transceiver to a WiFi access point, connected to the installation via a KNXnet/IP interface. The connection via the KNXnet/IP interface is described in detail in paragraph Direct access to a KNXnet/IP-Server Internet xdsl Ethernet KNX 3G/WiFi 3G/WiFi WiFi WiFi Figure 24 Schematic diagram of a mobile device visualisation Finding a KNX device with embedded visualization There is a plenty of visualisation software in the market for several types of mobile device operating systems. One just has to access the Store of the respective operation system Visualisation Systems Visualisation Systems_E1212a 23/26

24 via one s mobile devices ( Google Play for devices running on Android, App Store for devices running on IOS and Windows Marketplace for devices running on Windows Phone ), find and select the App fitting to one s needs. Figure 25 Apps for KNX visualisation for IOS, Android and Windowsphones devices Configuring a mobile visualisation software In most cases, the configuration of a visualisation App for KNX can be done in two ways. These are the following: Use of external configuration software, which is the most used and most preferable solution. With this solution, the developer can freely design the visualisation project. The project data (i.e. the group addresses) can either be o retrieved by importing the previously exported file from ETS, as described in paragraph 1.8 Exporting project data: Support by ETS, or o by adding manually all the necessary group addresses or o even using the automatic scan that many Apps include in their main functionality. Use of the embedded configurator of the App, mostly available in evaluation versions of visualisation Apps. In this case, one has to manually add all the group addresses or even scan them by reading the telegrams from the bus. Visualisation Systems Visualisation Systems_E1212a 24/26

25 Figure 26 App visualisation configuration tool and preview Figure 27 App visualisation configuration using the embedded configurator. Adding group addresses manually Client/Server based visualisation Since the very beginning of building management systems, there has been a need to visualise installations on central units with the ability to access them by several users and in many cases with different privileges. Usually a common PC connected to the installation played the role of central unit and other PCs connected to it played the role of users. However, since technology evolves, these devices have been significantly improved, and their size has also decreased. The solutions that exist in the market, are not limited only to conventional PCs, but include compact powerfull display devices with Ethernet connection, which can also have integrated support for audio/video, alarm or logic control functions. They can also play the role of visualisation server, where other display devices can connect as clients and supervise or control the installation Finding Client/Server based visualisation The visualisation solutions based on the Client/Server model that are offered by the manufacturers can either be - a standalone software tool, which is installed on a PC, thus getting access to the bus and other clients able to connect to it, or Visualisation Systems Visualisation Systems_E1212a 25/26

26 - a compact computer with an embedded, free to configure visualisation software and a KNX interface for the access to the bus. KNX visualisation software can be found easily at software and hardware developers just by through its name, while compact visualisation solutions usually have names such as KNX Server, Homeserver, or similar Configuring a Client/Server based visualisation Configuration of a Client/Server visualisation can differ from one manufacturer to another. However, the main principle to configure a standalone software is described in 1.7 Connection of the Visualisation to the Bus System. Visualisation Systems Visualisation Systems_E1212a 26/26