General / Introduction

An energy management system is used which can run independently as a stand-alone system. The system must be scalable, from a stand-alone solution to a distributed architecture. The aim is to make all energy and media-relevant data available in one system. This requires an energy management system that takes data from a partly heterogeneous system landscape. The data is stored in a central database. Data that is already available in electronic form is automatically recorded or transferred from existing systems. Data that is not available in electronic form, such as non-automated measuring devices or production data, is transferred manually to the energy management system. Web clients should enable access to reports and manual data entry of values. Web clients also allow the system and reports to be configured.

Furthermore, a user without programming knowledge should be able to define new key figures and output them in the form of reports or dashboards. The presentation of the data should be easily customisable to the respective user group.

Licensing

The system should be scalable in terms of the number of data points. It should be possible to expand the data points without a system update via a licence key.

Data acquisition and export

The existing system landscape requires data to be transferred from existing SCADA, BMS or process control systems, such as WinCC, DesigoCC or PCS7. In addition, values from the field level should be transferred using Modbus/TCP or OPC UA (HA and DA). Data from other database systems such as Oracle, SQL Server, MySQL, Access or Excel should be transferred manually if required, but also cyclically and automatically via OLE DB or ODBC. Data from the existing file system, which is available in the form of XML, CSV or TXT, should also be transferred from an FTP server (FTP, sFTP) if required, but also cyclically and automatically.

Distributed data capture must be supported, whereby appropriate pre-processing of the data must already be possible in the decentralised capture component. In order to achieve the required data quality and completeness, an appropriate buffer concept must be available in the event of a communication interruption. Communication between the decentralised component and the central system must also be possible in encrypted form.

Manually entered values should be able to be entered or changed via a suitable input screen. A simple plausibility check of the values (upper and lower limit, maximum increase, minimum increase) should be carried out directly during input in order to rule out any typing errors. Changes to measured values must be logged accordingly and also marked as changed in the report results.

The export of values for the existing billing system, for example, should take place in the form of a structured XML file format as required and also cyclically and automatically. In addition, it should be possible to provide the relevant billing data in MS Excel format, as a freely configurable REST API and for SIEMENS Insight Hub manually as well as cyclically and automatically.

For power monitoring, accompanying values from the measuring devices such as voltage, current or phase angle can be displayed in a short cycle time in tables or graphically in curves. Medium-term archiving takes place in the acquisition component. The displayed values are included in the standard licence.

Mobile data acquisition

The user must be able to record meter or consumption values via a mobile device. Immediately after entering the value, the user should be able to carry out a plausibility check of the value. The user should be guided through the halls according to a configurable route. In addition, the scanning of a barcode to identify the counting device should be supported.

Once the data has been entered, the values must be automatically transferred to the energy data management system. Synchronisation via WLAN should be supported.

At least the Android and Apple iOS operating systems must be supported.

Data quality

To ensure high data quality, a plausibility check for values should be possible. It should be possible to check values using upper and lower limits as well as the maximum and minimum value change between intervals. It should also be possible to check whether there are gaps in the incoming measured values of a data point. A check regarding the deviation from a value in a comparative time series and regarding the deviation from the previous month's or previous year's value. It must be possible to define the permitted deviation in absolute or relative terms.

Values that deviate from the plausibility limits should be displayed via a configurable message list or sent by e-mail. In order to obtain an overview of the data quality, it must be possible to generate a status report with the deviations at regular intervals and send it to the relevant persons by e-mail.

If necessary, it should be possible to automatically supplement missing values with substitute values. The following replacement value strategies should be possible as a minimum: Last valid value before the gap, value of a reference data point, static replacement value Value from the past (e.g.: 1 week ago).

Data processing

The system should provide a means of pre-processing or linking values before they are saved in the database. These can be both physical values (e.g. electricity consumption) and production data (e.g. number of units). Various mathematical functions are required for this, such as summarising second values to 15-minute values, conditional averaging, or determining minimum and maximum values, filter functions, angle functions and logical operators. It must be possible to map non-linear relationships using table functions.

In addition, it should also be possible to summarise or recalculate values that have already been saved in the database. This should be possible manually, cyclically and automatically as well as retrospectively. In addition to the basic calculation types, conditional calculations such as if-then calculations and threshold value functions should also be supported. It must be possible to calculate virtual counters using the full range of functions.

The corresponding key figures should be easy to add to reports and should be able to be calculated for different time ranges without additional configuration effort.

Even if the key figure is used in several reports or other key figures, it must be ensured that any changes only have to be made in one place.  

The recording and monitoring of greenhouse gas emissions such as CO2, NOX etc. should also be supported. CO2 monitoring and reporting for the automatic and plant-specific evaluation of material flows with emission and oxidation factors in accordance with the standard or mass balance procedure should be possible. Subsequent reporting to public authorities or other organisations subject to reporting requirements should be provided in the form of predefined report formats.

It should also be possible to historicise calculations so that changes to earlier calculation models can be tracked and compared with current calculation models.

Monitoring

A monitoring function is required for the timely observation/validation of energy and consumption values. Analysing and displaying (monitoring) is required not only for current values, but also for historical values from the database and for planned and target values.

It should be possible to display up to 10 hydrographs simultaneously in a trending tool. It must be possible to display up to 3 Y-axes in one diagram. The time resolution can be freely selected by the user. The display as a line, bar or point diagram should be freely selectable. To get a quick overview of the energy consumption of a week, the user should be able to select a reference week to be displayed in the same diagram. It should be possible to define the reference week either relatively (always the last week) or absolutely (always week 23).

It must be possible to display several data points simultaneously in a dashboard, so that, for example, daily, monthly and annual values can be displayed in a single overview. Possible display formats are bar charts, pie charts, line charts, numerical values, values in table form, difference values to reference data points, display as a gauge and status displays of values, e.g. using traffic lights or simple status displays.

The current energy and media flows are to be visualised in the form of energy flows (arrows, bars) in a dynamic process diagram Sankey diagrams.

Controlling

The system must support the calculation of key figures and the comparison of these key figures with, for example, the previous month's or previous year's values. Furthermore, it must be possible to balance energy flows to determine production-related key figures, target/actual analyses of energy consumption or costs for different time periods, both in tabular and graphical form. It is also necessary to analyse key figures from the beginning of the month or year up to the current date, for example. Key figures such as efficiency ratios should be calculated and graphical analyses such as annual duration curves, hourly distributions, weekly and daily curves for any period of time should be output (minimum: 15-minute grid).

The system should enable the calculation or mapping of efficiencies or system-specific characteristic curves. With specific evaluations such as regression analyses, it should be possible to compare consumption values with production values. The key figures determined in the system should be able to be compared with benchmarks and target values and thus enable the comparison of locations or plants. For this purpose, it is necessary for the system to offer the option of standardising key figures in order to be able to take site or weather-related influences and conditions into account to the same extent, for example.

Appropriate functions must be available to determine the energy consumption per material or per batch.

The system should make it possible to determine the energy and media consumption (electricity, gas, water, steam, etc.) as well as the carbon footprint of a batch or product over the entire production process. It should also be possible to evaluate individual production lines in terms of their energy efficiency by analysing different batches on which the same material is produced. To do this, it is necessary to record batches, including the associated material that is produced, across several systems. A clear allocation of material and batch must therefore be guaranteed.

Energy billing

Energy consumption data as well as energy costs should be balanced according to source and correctly allocated to cost centres. The system should be able to map the company's internal billing structure and take any loss factors into account. This requires the mapping of tariffs such as performance and labour price, high tariff / low tariff, or taxes and levies as well as the proportional allocation of energy consumption to individual departments, systems, cost units or products or batches.

It should also be possible to check incoming invoices on the basis of the mapped contract.

The system must support a high degree of flexibility in the definition of cost centres. Changes must be logged and the user must be able to make them easily and without programming knowledge. The allocation keys can either be fixed for a period or calculated using measured information. The allocation is made as a percentage or in absolute terms. The cost centre information should be able to be output in MS Excel reports so that they can be passed on directly to the controlling department or sent automatically, e.g. by email. The system should offer the possibility of a transfer in the form of a structured XML file format to the company's internal accounting system (e.g. SAP R3).

Energy efficiency in accordance with ISO 50001

ISO 50001 requires continuous improvement of energy consumption behaviour and sustainable tracking of improvement measures. The system should support the requirements of ISO 50001 in such a way that measures to increase energy efficiency can be recorded, managed and evaluated according to economic criteria. Relevant economic evaluations in this context are the amortisation period, the return on investment (return on investment) or the net present value.

The system supports the fulfilment of the requirements of the following chapters of the DIN EN ISO 50001 standard:

6.2 Objectives, energy targets and planning to achieve them

6.3 a), b), c) Energy evaluation

6.4 Energy performance indicators

6.5 Energy baseline

6.6 Planning of energy data collection

9.1 Monitoring, measuring, analysing and evaluating energy-related performance and the EnMS

9.3 c), d) Management review

The system supports the implementation of the requirements of the following standard chapters of DIN ISO 50006:

4.2.4 Determination and quantification of relevant factors

4.2.5 Determination and quantification of static factors

4.3.3 Determination of the specific energy-related performance characteristics to be quantified

performance characteristics to be quantified

The SIMATIC Energy Manager PRO and Energy Manager App components support the implementation of the requirements of the following standard chapters of DIN ISO 50015:

5.3 Measures to improve energy-related performance

In addition, the system supports the fulfilment of the requirements

the following chapters of the DIN EN 16247-1 standard:

5.4 Data collection

5.5 Analysis

5.6.2 Report

Planned measures for all locations must be recorded centrally and assigned to a region, department or plant. The ability to prioritise planned measures is also relevant. Furthermore, it must be possible to record responsibilities and project progress. It must be possible to record and calculate relevant data such as consumption, costs and emission savings as a basis for deciding on measures. It should be possible to output the planned energy efficiency measures in reports and filter them as required. Once an energy efficiency project has been implemented or completed, it must be possible to compare the planned savings with the savings achieved in order to show the actual improvement achieved.

Savings targets can be displayed for energy as well as CO2 and costs.

Meter management

In addition to power and consumption data or flow rate and quantity, it must also be possible to record and save ascending meter readings. The energy management system must have appropriate configuration options to be able to configure a meter constant and the counting range up to an overflow.

The system must be able to correctly process multiple overflows in a calculation interval. It must be possible to subsequently configure any meter replacement. It must be taken into account that a new meter may have a different meter constant.

Automated reporting

Calculated key figures should be output in report form, whereby predefined time periods such as day, month, year, but also freely selectable time periods must be available. Reports should be freely definable so that the output of key figures and the necessary intervals can be individually defined. It must be possible for people without programming or database knowledge to create or change reports.

Reports should be able to be calculated automatically in different cycles (shift, day, month, etc.). In addition, it should be possible to send reports automatically to printers or e-mail addresses, or to store them in a directory.

It should be possible to output and send the reports either in MS Excel or in PDF format.

Master data management

Energy management-relevant documents must be able to be uploaded to the system and should be made available for download to a user group corresponding to the authorisation concept.

It must be possible to enter general information such as contact persons, meter types, suppliers, etc. into the system. It must also be possible to output this freely defined information in the reporting system.

Provision of information via the web

It must be possible to publish all reports, trends and dashboards on the intranet/internet without additional configuration. It must also be possible to retrieve uploaded documents via web access. The user must be able to carry out analyses on the database. They should also be able to comment directly on individual values (outliers). This information must also be available to other users.

It should be possible to restrict the view and functionality of the user groups via a suitable authorisation concept.

Each user should be able to create quick links to the information they need most frequently.

To ensure data security, encrypted communication between the web server and the web client must be supported (https).

Planning and forecasting

The system must have suitable forecasting models to cover the requirements of short, medium and long-term forecasting (day, month, year).

Different factors form the basis for the values to be forecast. On the one hand, the system should enable a forecast based on the known correlation between production and consumption.

If the energy consumption follows a recurring pattern, e.g.: typical days with a weekly load profile or production sequence according to shifts, it must also be possible to make a forecast based on this, taking into account public holidays and other production-free days. It should be possible to import the public holidays from a file (Outlook .hol).

In addition, it should be possible to make a forecast based on production plans, taking into account the different energy consumption of certain products or materials. It should be possible to calculate the corresponding material-specific parameters using a batch/material analysis.

A multi-dimensional regression analysis can be used to make predictions regarding the expected energy consumption, e.g. the influence of the outside temperature on the heating requirements of a building.

Authorisation concept

It should be possible to adapt the view of the system to the relevant user group via an authorisation concept. In addition to restricting the view, a restriction of functionality must also be supported. A single sign-on concept must be available for people who carry out engineering in the system on a daily basis.

Availability

A suitable concept must ensure the availability of the system; this requires in particular that appropriate buffer mechanisms are available in the event of an interruption in communication between the recording component and the central database. Automatic updating of the stored information must be ensured.

A corresponding online backup and recovery function must be available.

Security

In order to fulfil the IT security requirements, it must be possible to define the requirements for a password. (e.g.: at least 6 characters, at least 1 special character) It must be possible to define the time after which the user must change their password. The last 3 passwords must not be assigned again. If the user has forgotten his password, he must be able to request his password. A corresponding message should be sent to the user by e-mail.

Service and support services

The Provider shall provide telephone and e-mail support, Internet information and software training.

The provider provides worldwide technical support for the entire scope of the software. The Provider offers a published telephone support number during normal business hours. The Provider offers comprehensive technical support available via the Internet, which includes, but is not limited to, the following services: Email contact with technical support, knowledge base with search function, product catalogues and manuals, FAQs, application examples.

The provider offers a software update service with automatic dispatch of new product versions.

Link to the Siemens Industry Mall

https://mall.industry.siemens.com/mall/de/WW/Catalog/Products/10061948?tree=CatalogTree