IBM Podcast [ MUSIC ] Welcome to this IBM podcast, Role of Software in Smart Grid Transformation. I'm Angelique Matheny with IBM. Energy and utility companies have traditionally focused on their core business of distributing electrical power in a reliable and efficient manner. With the adoption of smart grid, electric power distribution is coupled with bidirectional and frequently copious data exchange. The underlying data is defined through standards from IEC, and a set of best practices is essential to implement and manage this new data-centric paradigm. And here to discuss this topic is Irv Badr, IBM's Global Market Manager for energy, utilities and communications. So welcome to Irv, welcome to the podcast. Thanks for joining us today. BADR: Hello, Angelique. Let's just jump right in. My first question is, how important are requirements management in the successful implementation of Smart Grid data, namely common information model? -1-
BADR: Well, Angelique, CIM is basically a notation that we use for Common Information Model. And the reason requirements are very important is because we always have requirements and no matter what task we undertake, the chances are greater that your requirements are simple enough that you can put them in a Microsoft Word document or Excel spreadsheet with different line numbers and tally if each requirement has been satisfied. However, when you're talking about a heavily regulated and standardized industry as energy and utilities, it's very difficult to maintain the requirement. And the reason is not because there's too many requirements, which is true, there are too many requirements, so it can't be managed actually in an Excel spreadsheet, for example. However, more often than not, those requirements are interconnected. We call them coupled requirements or interdependent requirements. And we end up with a matrix of interdependent requirements that impinge upon each other. So one requirement is satisfied if only three other requirements were satisfied; however, those three in turn could be dependent on the first requirement that we mentioned, in a circular manner sometimes. -2-
So those things have to be resolved and need to be implemented, and oftentimes before we realize there's a circular requirements problem or more so a duplicated requirements problem and as we all have experienced, missed requirements. So what usually happens is that the requirements end up getting not just changed but deleted, added, and more often than not it causes quite a lot of disruption in the course of a project. And energy utilities are definitely not an exception. We have not one team in a utility company sitting and developing solutions. Energy companies seldom do all development themselves; they outsource quite a lot of the work. A lot of the software used by energy companies are off the shelf. A lot of the database products and DBMS-type systems are all purchased. So what happens then is that the requirements tend to bind all these disparate pieces of software, some developed, some outsourced, some purchased into this continuous deliverable. So that's one of the reasons there are formal requirements management, it's very important from a tooling perspective, and IBM and Rational as a tool company are very conscious of the fact that if we do not impose formalized requirements through requirements managements tools, it's very easy to lose control of the project. -3-
So what we end up doing is requirements are part of the project management collection and they are linked to the development or integration or delivery activities. So when you're delivering a piece of energy and utility software, you end up tracing each piece or each component of that delivered application to a set of requirements, one or more requirements, and in an automatic manner through tool traceability. The requirements, you click on a requirements management, tool you'll be able to go into the implementation, either as a [modder] or source code of that requirement, to see if you have covered that requirement. So that whole science is called requirements coverage. What also comes out of it is requirement slippage analysis, where we have an implemented system and then we can go back and see that there's a pure retirement that nothing is being traced to. Those are what we call dangling or untraced requirements, which tells us that we've missed something and then we go ahead and try to resolve those. So as formalized requirements, I gave you a very simple overview, but as you probably guessed, it could get fairly complicated. As a result, at Rational, when we have Common -4-
Information Models --CIM -- based developed, some of the CIM components are placed directly inside the software development tools like Rational Software Architect, RSA, or Rational Application Developer, RAD. Those CIM components are basically the data models of the CIM classes. However, they trace also to the CIM component inside requirements managements tool. Currently the requirements management tool we have at Rational are either Requisite Pro from Rational, or DOORS, D-O-O-R-S, from Rational. Depending on your requirements structures, either one of those two tools would be used. And CIM presence in those requirements management tools incur a lot of development tools like RSA and RAD, Rational Application Developer, allows them to be traced to each other's requirements to the development tool, and we automate the process of requirements management side for the successful EU project. You just mentioned some IBM Rational tools and implied for modeling the data. Do they need to be integrated with the requirements tool? BADR: Yes, I mentioned two tools for development that are practically used for a set of best practices that we recommend. Depending on your adopted processor or workflow, -5-
some people in some organizations in energy and utility have model-driven development through notational tools like UML, architectural tools like UML, sys ML. Those are all modeling paradigms. We have those, and then some people tend to use more source-oriented processes without the models component added. That's covered through RAD, Rational Application Developer. Both of those development tools -- RSA and RAD -- are linked with the requirements management tool. So CIM traceability is the same no matter if you're using RSA, Rational Software Architect or Rational Application Developer. The same CIM is traced from the development tools that I just mentioned. Irv, do you have any customer stories for those customers who have undergone this set of best practices you just mentioned? BADR: Yes, and I can classify some energy-related customers because today the discussion is centered around energy. We have multiple levels of energy customers, quite a few of them, that have used best practices that we are talking about today. We should start from standards. Standards organizations such as IEC, which you mentioned first, International -6-
Electro Technical Consortium, I think it's called. IEC is an international body of the standards. And the CIM's information model is an intersection of two standards known as 61968 and 61970. So when we have the CIM-based customer, IEC-like standards organizations are the foremost and most visible group of our customers, where they take the tools like the Rational Software Architect, which are the UML modeling capability, and implement some of the standards and publish them in RSA. Similarly, another standards organization is EPRI, EPRI, it's called for energy and utilities, they have done a proof of concept type project called Intelligrid and that's, for example, going to be used using RSA. So those types of tools can be considered a customer...the tool organizations can be considered a customer of ours, but the bulk of our business, existing business with energy and utilities, is revolving around the companies themselves, the utilities themselves. And so far we have had very good luck with major utilities in Southern California and all the other states. They're too numerous to name, but Southern California, though, is one of our beachhead accounts where they're using the full best practices that we are recommending today, full -7-
requirements traceability, full formal development method and development tools like RAD or RSA. And, full, sometimes testing solutions, full project and portfolio management that is also part of our solution. And some testing as well. So those customers are not just California centric, but, for example, in Texas, the Austin area, a power company is one of our first customers in the U.S. to adopt our best practices. And now we're moving towards more national type organizations like National Grid, and a lot of the IBM solutions are being adopted there. We also are growing fairly fast in the East Coast energy companies, since there's a lot more there because the states are a little smaller, some with multiple electric companies. And then the European and Asian businesses are fairly stable, and we have, for example, DONG Energy in the Northwest Europe, they have purchased [INAUDIBLE] best practices from us for a number of years in their multiple stages of adoption of the tools, as is the Japanese and China, main electric company in China are using the same set of best practices. So, I also wanted to add quickly that these best practices, even though they're energy and utility centric, energy and utilities is not a simple industry; it is sometimes a -8-
combination of multiple industries. And the underlying systems for energy are as a result much complex, they're more systems of systems versus just being a single monolithic system. So, for example, one of the big areas, one of the big subsystems in the energy industry, is in generation side. For example, nuclear energy happens to be a very unique generation entity, so does the solar or wind farm. It's a very unique generator of energy, and some of these best practices have slight tilt to them for those generation entities. So, for example, when you're talking about the nuclear energy, you will not deploy the CIM verbatim as I mentioned for general energy usage at the MDM level or any other part of the intelligent utility network. The solution I'm mentioning will be slightly tilted toward nuclear regulations and then CIM requirements traceability that RSA or RAD would be used, but in a different standard, maybe NERC or FERC-type standards more so than the CIM. The same thing with the wind and the solar bank suite. We have different set of standards that govern those. So, we have several customers in all those areas I mentioned: nuclear, wind farms, solar farms, as well as the conventional E&U generation system and E&U companies. -9-
We can provide you more concrete reference if anybody's interested. We have all this. Irv, our last question today, what is a typical learning curve for a delivery team who has very limited experience or new experience with modeling tools and formal requirements management? BADR: Well, that is actually a fair question, because the majority of the energy utilities companies before the smart grid mandate were not software centric. Most energy companies and managers and the staff, underlying staff for that matter, are all electrical engineers or hardware device and equipment-oriented people. So when the smart grid transformation is now imposed on all of these companies, it is a paradigm shift. So this is more of a culture change for energy companies than any other organization that is adopting best practices based on model-driven approach or, let's say, add formal requirements traceability and requirements management on top of that. The good thing about energy companies is that the engineers tend to be more technical in a way that they have very keen passion for quality and energy is a very, it's a risky business if you're not safety sensitive and also reliability sensitive. The penalty for not being any of those things is -10-
very big. So, software as a result is done in a very systematic manner, and the process of software integration required more energy companies than in my experience have done it in a very systematic and organized way. So Rational is fully aware that no new group or energy company will come up start doing UML modeling and start generating data definitions and data implementations for CIM right away. So we have this gradual deployment plan that we recommend to our energy clients where Rational services along with IBM General Business Services type of organizations pay visit to the customer, assess their capability, assess their goals and their requirements, followed by a quotation of the work order......where we can tell the customer that we will start you off in a quick start type of a program with the tools and services and gradually taper the services side off and increase the tools adoption more as the customers get more and more adept with this new work flow, the process, development process and the tools. And our experience is between four to 18 months depending on the team and their interests and their budget, that hand-over process happens in a very smooth manner where the -11-
Rational team hand over the project 100 percent to the utility team. But at the beginning, the project is mostly dominated by the Rational and IBM services people, along with the native E&U team. Irv, thank you so much for sharing your time today. We really appreciate it. BADR: My pleasure. Anytime. Thank you, Angelique. That was Rational's Irv Badr talking about the role of software and smart grid transformation, a software-centric delivery process and a set of best practices that center around software integration and development. To share this podcast with your colleagues, or if you're interested in more podcasts like this one, check out the Rational Talks To You podcast page at www.ibm.com/rational/podcasts. We'll post a link to the solution brief, Helping Utilities Bridge the Gap to Smart Grid. Be sure to check it out today. This has been an IBM podcast. I'm Angelique Matheny. Thanks for listening. Keep tuning in as Rational Talks To You. -12-
IBM Podcast [ MUSIC ] [END OF SEGMENT] -13-