The second season of Smart Talks is dedicated to utilities and massive rollout.
This is the first part of the interview with Mr. Nenad Medjeral who is a Chairman of the Technical Board of the IDIS Association since 2018. He shared his knowledge about defining and creating IDIS’ specifications, why it’s important to have a precise definition of the communication protocols, and talked about the use of different technologies during a massive rollout.
You are currently holding a position of a chairman of the Technical Board of the IDIS Association. Can you tell us something about your job within the Association as well as some of the goals for the future?
I was a member of the Technical Board since the very foundation of the Association, and I’ve been a Chairman of the board since 2018. The Technical Board is responsible for the creation of IDIS’ specifications, defining the conformance test plan and certification process.
The base for IDIS specification is DLMS specification and the equivalent IEC standards. In case that there are some other protocols or specifications being used, they have to be a part of the international standardization. Everything that’s done, is done on the basis of the already existing technologies.
In general, IDIS specifications are created to be independent from communication channels and to enable use of as many existing communication technologies as possible.
The emphasis is on precise specification of the application level and reducing the number of possible options to a minimum. With such approach high level of interoperability can be achieved. Which reduces integration cost and risks during roll-out. If a utility uses the smart meters from different distributors in a same AMI-system, the system should communicate with them in same manner.
What happens if something is not covered by DLMS?
In case that IDIS Association recognize that a specific use case cannot be covered by existing DLMS specification, it proposes to DLMS User Association (DLMS UA) to include the use case to working program. The proposal is accompanied by use case description and initial draft of specification. Further specification development and release is governed by DLMS UA.
We also cooperated with OMS (Open Metering Systems) on the multi-utility solution. Thanks to that we define the multi-utility use cases supported by both associations.
What communication technology/specification would you recommend to utilities planning a massive rollout?
That is a question with no easy answer. There is variety of communication technologies on the market. Selection of the communication technology should not be based only on technology parameters like bandwidth, penetration, maximum number of nodes, etc. Besides those parameters important are technology maturity, availability on market, coverage, deployment and maintenance cost, performance and cost should be balanced. Matrix is quite complex and there is no simple recommendation. The communication technology should fit to utilities’ eco system with acceptable total cost of ownership.
It could happen that optimal solution can be achieved with usage of two or more different technologies. Today, we often see the mixing of technologies because of multi-utilities, home automations, building management, etc.
Some utilities may also choose the option to use an AMI managed service. In that case, everything is done through the service: communications, taking care of the smart meters, etc.
In addition to choosing technologies, we need to talk about which ones are currently standardized for interoperability. Can you tell us more about the importance of having true interoperability (interchangeability) in the field, during a massive rollout?
Utilities usually choose multiple vendors of devices or technologies because of their business needs. If those devices are integrated in an AMI system and support very same use cases, their interfaces must be well understood and behave in same manner to reduce investment risk. Therefore, it is important that selected communication technology is well described, with stable and well-maintained specification.
As important is the precise interface specification, it is also important to have the device certification in place to prove device conformity with the specification before installing it in the field. Certification is one of key mechanisms used to achieve high level of interoperability, avoid misbehavior of device on specified communication interface and prevent different interpretation of the specification.
IDIS association includes in the specification the communication technologies built on international standards, proven in the field, and covered with certification process.
Using interoperable devices reduces integration time and cost, unifies deployment process, and reduces risks.
What communication technologies has the IDIS Association standardized with its specifications and certification programs? Does it cover and standardize everything for projects that combine two communication technologies?
Today, the IDIS specifications covers multiple communication profiles. The first specification package covers single communication profile which is S-FSK PLC. The second specification package covers the IP (Internet Protocol) based communication profiles, G3-PLC, GPRS, UMTS, LTE end Ethernet. The specification and certification can be easily expanded to any other communication technology that interfaces with the upper communication layers over IP layer.
The scope of the IDIS specification is interoperability of communication interface on application level. The specification is created in such way that application level is communication agnostic as much as possible. The communication profile specific objects are managed as options. Therefore, from the IDIS Association perspective, usage of multiple communication profiles (technologies) can be treated as separate communication profiles and device conformance can be tested and certified per communication profile. It would be already possible to implement and certify device which supports two communication profiles based on the existing IDIS Package 2 specification.
Conclusion:
Generally, IDIS specifications are created to be independent from communication channels and enable the use of different communication technologies. The emphasis is on the precise specification of the application level. This means specifying all functionalities, but also some necessary details for communication technologies.
Therefore, IDIS specifications and certification programs can also be used for applications in which two communication technologies are used. Of course, in case of requirements for some new functionalities during such application, new use cases should be created to define them. IDIS specifications essentially do not depend on communication technologies and can support two or more.
In your opinion, is it necessary for all the functions used during a massive rollout, to be defined by the appropriate specification and confirmed by the appropriate certification program?