We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Business Transformation in Action

Joe McKendrick

More Electrifying SOA

user-pic
Vote 0 Votes
SOA is playing a supporting role in helping manufacturing organizations gain better efficiencies from the large range of devices, many of which previously were unable to talk to each other. A new article by Sarah Falson in Process and Control Engineering describes how Schneider Electric,one of the world's largest equipment and solution providers, enabled its Australian unit to help its manufacturing customers to better leverage its infrastructure with service-oriented approaches.

In the case of Schneider, SOA is playing a role in underpinning its SCADA (Supervisory Control and Data Acquisition) offerings, which enables businesses to integrate their plant information for the benefit of increased output and simpler maintenance. According to Falson, "SCADA translates different sources of information - for example temperature, conveyor speeds, power use and product/materials volumes - into a single database, connecting it together into a uniform report for plant operators to use." With SOA, there may also be connectivity to higher-level enterprise information, such as finance, human resources and inventory.

Before SCADA, plant operators had to travel around the plant, measure each piece of information manually, and collate it  -- and each piece of equipment used a different, vendor-based protocol. "Nowadays you can sit in front of the SCADA system, which talks to all the dissimilar devices out there in the plant, polls them in real-time, collates all the information and presents it in one summarized view for the engineer to use to pinpoint a problem area," according to Schneider Electric Vice President Chris Crowe.

The company is employing SOA-based practices to enable applications running within this equipment to connect and share information across a common service layer. "Service-orientated architecture is changing our world," Crowe said. Many large customers are also demanding SOA compliance, he added.

Appreciation is expressed to Harm Smit, who provided additional clarification about SCADA and the role of SOA in manufacturing for this post. He observes that "SCADA software operates at the same level as Manufacturing Execution Systems, that is, at or just above the level of plant floor devices (all kinds of sensors, conveyors, grippers, valves, etc.)."
 
He also notes that "devices become smarter and smarter, enabling them to expose functionality (services) of a higher level than was possible before, thus constituting self-contained, autonomous entities that encapsulate their own complexity. Ultimately, devices should be capable of monitoring and diagnosing their own operations rather than rely on some higher-level entity. This evolution will of course change the way in which devices will be conceived, used and integrated."

2 Comments

user-pic

Joe, both your article and the one it refers to contain quite a few instances of improper terminology, fuzzy statements or plain errors. Here are some comments (quoted text followed by remarks introduced by '->').

Your text

"Schneider Electric, an Australian utility"
-> Schneider Electric is neither Australian nor a utility. It is one of the world's largest equipment and solution providers in areas like industrial automation, home & building automation, electrical distribution, etc. It is headquartered in France, but has several subsidiaries operating in Australia, one of these being the company formerly named Citect, acquired by Schneider Electric a few years ago.

"SOA is underpinning the utility's SCADA (Supervisory Control and Data Acquisition) approach, which enables businesses to integrate their plant information for the benefit of increased output and simpler maintenance."
-> The link with SOA is unclear. I can see two ways in which the SCADA package uses SOA principles: either the SCADA package exposes its functionality to the outside world in the form of services, or it communicates with its information sources in a service-oriented way. The latter supposes that the information source devices themselves expose their functionality as services, which the SCADA package cannot impose in any way.

"SCADA translates different sources of information − for example temperature, conveyor speeds, power use and product/materials volumes − into a single database, connecting it together into a uniform report for plant operators to use."
-> This is correct, but bears no relationship with SOA.

"SCADA systems also measure enterprise information, such as finance, human resources and inventory."
-> SCADA has nothing to do with this type of information, which typically belongs in the realm of ERP systems. SCADA software operates at the same level as Manufacturing Execution Systems, that is, at or just above the level of plant floor devices (all kinds of sensors, conveyors, grippers, valves, etc.). In contrast, ERP systems operate at the enterprise level and there is actually a disconnect between these levels. Applying SOA principles and associated technology may help bridging this gap.

Sarah Falson's article

"If every device on the plant floor becomes internet- or IP-aware, getting information from each device which carries a sophisticated brand protocol would be easier. Everything could connect everywhere."
-> That's correct, but the real breakthrough would be to get rid of proprietary protocols on top of IP and, instead, create a uniform standards-based communication infrastructure. For example, when addressing a temperature sensor, a SCADA package needs to know the sensor's brand and version, since different brands use different protocols. A big stride forward would be to have every temperature sensor expose its functionality in a standard, service-oriented manner. This was the idea underlying the Universal Plug and Play (UPnP) protocol family, which has been taken one step further by the Devices Profile for Web Services (DPWS). Contrary to UPnP, DPWS is fully based on Web Service protocols; it was recently approved as an OASIS standard. In order to achieve the goal just mentioned, DPWS should be complemented with domain-specific standards.

"SOA is all about allowing various business applications to talk to each other and share data, as a cost-effective solution to improving total system quality."
-> SOA is in no way restricted to business applications. An interesting aspect of the SOA paradigm is, precisely, that it is general enough to cut across many different layers of system functions.

"This includes distributed smart embedded components or devices with communication, information processing and embedded intelligence."
-> Agreed. Devices become smarter and smarter, enabling them to expose functionality (services) of a higher level than was possible before, thus constituting self-contained, autonomous entities that encapsulate their own complexity. Ultimately, devices should be capable of monitoring and diagnosing their own operations rather than rely on some higher-level entity. This evolution will of course change the way in which devices will be conceived, used and integrated.

"Today you’ve got so many operating systems including Cisco, IBM, Microsoft, SAP, SCADA, and MES, all doing their own thing."
-> This statement is a bit awkward. Only a few names in the list have anything to do with operating systems and, obviously, SCADA and MES are different types of animals than Cisco, IBM, Microsoft and SAP. The point to be made here is that heterogeneity is the name of the game and that a technology-neutral, service-based infrastructure adopted by all players is needed to allow for interoperable communication between entities that use heterogeneous implementation technologies.

"SOA is a global standard."
-> Awkward terminology again. SOA is not a standard, it is simply a set of archirectural principles. SOA can be implemented in various ways, but in order to achieve interoperability, usage of universally adopted standards is mandatory. In actual practice, Web Services are the most prominent SOA implementation technology. Web Service standards are supported by all major enterprise software providers (IBM, Microsoft, SAP, Oracle, Progress Software, Software AG, ...).

"CitectSCADA customers including mines and processing plants are increasingly demanding SOA compliancy."
"We’re developing our infrastructure within the SOA framework."
-> Again, "SOA compliancy" and "SOA framework" are misnomers. Presumably, whenver this article mentions "SOA", it really means "Web Services".

Thank you for these clarifications, Harm. I have incorporated your observations into the original piece.

In this blog (formerly known as "SOA in Action"), Joe McKendrick examines how BPM and related business and IT approaches can promote business transformation.

Joe McKendrick

Joe McKendrick is an author and independent analyst who tracks the impact of information technology on management and markets. View more

Subscribe



Subscribe in Bloglines
Subscribe in NewsGator Online
Add ebizQ's SOA in Action Blog to Newsburst from CNET News.com
Add to Google

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT