EcoStruxure Building Operation Blog
Follow the EcoStruxure Building Operation stream and stay up to date with the latest news and helpful information.
Link copied. Please paste this link to share this article on your social media post.
Originally published on EcoStruxure Building Operation Blog by UlfMagnusson | October 13, 2020 01:24 PM
The term "reporting" is a very interesting term in our line of work. If you ask a bunch of people you will get very different answers. This means that the authors' objective from a few years back was not so easy; leadership asked me to "fix our reporting".
My task was given to me in response to quite vague feedback from most markets. Most people would agree that our reporting at the time was weak. But what does "weak" mean, what were the problems, were there any opportunities, what was good - many questions and I started from the customers' perspective. During a few months I interviewed end users to be able to get some facts. Following that I also interviewed many integrators; both Schneider Electric employees and EcoXperts and partners, to also get the installer perspective.
Several pains and problems were identified and prioritized, usage statistics was gathered, and general feedback was collected. If we for example look at the usage statistics of WebReports, or Building Operation Report Server, we concluded globally 10% use it at all. Of those 10%, the majority, 6 out of 10, use it to extend the capacity to store historical data. 2 out of 10 use it to meet customer requirements of data availability and openness and 2 to get data out in certain formats where Excel was the most popular followed closely by PDF.
We also collected as much examples of reports as we could during this time. This was not so easy. I have not analyzed why that is, but I have a feeling that the reporting capabilities was so hard to use, so many installers and customers were not very proud of their examples.
With the data at hand we explored the possibilities of improving the Report Server, explored the possibilities of adopting other 3rd party reporting systems and several other options. With regard to the Report Server, if was quite obvious to most that the investment needed to make it get anywhere close to where our customers and installers needed it to be, was not going to lead very far so we decided to initiate the work to discontinue it. This work is still ongoing, but the date is getting closer and closer for every release.
The "Fix our reporting" initiative was rebranded to "Enhanced reporting". And based on the collected requirements and feedback we identified four parts of the initiative:
1 High capacity historical data storage
2 Dashboards
3 Easy Excel output
4 Custom, paginated, automatic reporting
1, 3 and 4 springs right out of the usage patterns for the Report Server, but 2 does not. The Dashboards initiative was born out of the extremely common feedback from installers who had become familiar with PME or Energy Expert. Throughout my market research I kept hearing "We need dashboards like in PME!". So, "why not just use PME then?", was many stakeholders' response. Too hard to install and maintain for just basic or small installations, too limited in what kind of data could be presented, not real time, were a few reasons. This very strong and common feedback made us start the Dashboards development that you may have seen in EBO 3.x.
We decided to start with high capacity storage, dashboards and easy excel output. The first delivery of easy excel output came already in 2.0 with the Export to Excel functions in Trend lists. We have since gradually extended the ad-hoc output to Excel capabilities.
The priority of the custom, paginated, automatic reporting was intentionally put a little bit on hold due to other priorities and that we wanted to wait for feedback on the other initiatives.
Then it happened; we decided to implement support for new functionality that is required by customers in the life sciences industry. In this initiative, reporting was identified as something that was highly important, and when researching, we discovered an almost 1 to 1 match of the requirements with initiative number 4 from above. So, we started the development of what would lead up to the functionality that is new in 3.2.
For the life sciences industry and other critical installations, it is very important to ensure that reports are accurate representation of the data in the database. Also, customers need to report on any type of data in Building Operation, not only historical. For instance, customers want to be able to use the reporting system as a means of documenting configuration and permissions. This led us to decide that we wanted the new reporting system to be built in; you should not have to send data outside of Building Operation just to report on it.
Also, we wanted the reporting solution to work without the optional External Log Storage function (TimescaleDB). Another reason to build it in.
We build on functionality that was already related; the Notifications. Notification was previously used for text file output and had several of the properties of what would be needed. We prioritized getting the core functionality out on the market, with the acknowledgement that users will have to be quite an expert to make reports from scratch.
We researched various technologies and found that the open spreadsheet format XLSX was well suited. Many, many people are very skilled at using Excel and alternatives. Much broader user base than for instance SQL based reporting editors. The XLSX format can be both read and generated by the embedded version of Building Operation. And XLSX have a rich feature set for representing data using graphical elements such as charts, conditional formatting, spark lines etc. In addition, the format is open and not limited to Microsoft Office programs.
EcoStruxure Building Operation is a distributed, scalable systems that can be used in installations that range from single small buildings to global enterprises and we wanted the reporting solution to be possible in all kinds of installations. This was another reason we built reporting into the servers. Now even the smallest sites with only a single SmartX Edge Server (aka AS) can generate nice reports.
One additional and very powerful feature is available on the Windows based servers – PDF conversion. Enterprise Server and Enterprise Central can automatically convert the XLSX output to PDF. This without any dependency to any other software that you must install. We basically have a full equivalence of Microsoft Excel built right in so that we can convert the XLSX output to PDF with pretty complete support for all things that Excel can do; advanced calculation formulas and all forms of diagrams.
When you make reports in PDF, you get even better platform independence. PDF viewers are built into most web browsers and are available on even more platforms than XLSX.
Another new feature of 3.2 is very helpful for reporting. If you want to report on something that is calculated from historical data in EBO, you can of course use the powerful calculation possibilities within XLSX, but there is one problem; you may want to use the result of the calculation for other things within Building Operation. Maybe you want to present the calculated result in Dashboards, alarm on it or present in traditional trend charts. Or ensure that the data in TimescaleDB is stored in a way that is easy for other systems to interpret. This is where the log processor comes in. The log processor can perform calculations on one or multiple trend logs and results in one new trend log that you can use in any way inside Building Operation the same way as you would use any other trend log.
So what is it that you can do more in detail: you can convert trend logs between different units, you can make new logs that contain only max, min, average of delta for configurable periods (downsampling), you can add, subtract, divide or multiply logs and point values (normalization and benchmarking), you get make the calculations on the fly when requested or you can have Building Operation perform the calculations in the background and store it in the database - including TimescaleDB. You can chain multiple log processors, you can specify exactly how you want the timestamps to be set and you can convert timestamps between different time zones. A pretty powerful object type that you will find under New->Trend->Log Processor.
The log processor enables you to arrange data exactly how you want it. This makes it so much easier to build XLSX reports for it. And more.
We know that it can be quite complex to build reports from scratch and we will be looking into ways of simplifying and making reporting more geared towards end users and less experienced personnel in the future. I do see some strong synergies with particularly one other initiative that is ongoing; “Semantic Tagging”, that for instance would enable us to make report templates that works globally. But more about that in a future article.
I hope this gave some insights into the thought process that resulted in 3.2 reporting. Please let me know how you like this blog post in the comments and feel free to also post feedback about the reporting if you have had the chance to try it out.
Also, don’t forget that there is training available on the reporting, and many other areas of functionality in Building Operation, on My Learning Link!
Link copied. Please paste this link to share this article on your social media post.
All registered members have full access to the Community and can post comments and start topics.
Create your free account or log in to subscribe to the forum - and gain access to more than 10,000+ support articles along with insights from experts and peers.