Rabu, 23 Maret 2011

Executions Project Sample


PROJECT: ENERGY MONITORING & PRODUCT LOADING SYSTEM




FEATURES:
  1. Web based platform to launch an application that would monitor the daily, weakly, monthly energy activity.
  2. Track the Energy consumption for total plants.
  3. Build a secure log in the web that can be accessed by company management personnel
  4. Connectivity; modbus TCP/IP providing high data transfer rate 10/100mbps over 1 to 1.5 Km. 


SCHEME:
The entire Energy monitoring System comprises of various meters (includes different makers) to measure Electrical Energy Parameters like Kwh, Current, Voltage that need to be monitored & logged by a SCADA System. The system acquired data thro’ Modbus TCP/IP converter.


PROJECT : UTILITY AUTOMATION


FEATURES :
  1. Connectivity between Devices and PLC though Profibus PA.
  2. Connectivity between two different SCADA through OPC server.




SCHEME :
The Utility Automation comprises of various Instruments to measure Process Parameters like FLOW PRESSURE, LEVEL, TEMP and Electrical.
Energy Parameters that need to be monitored by a Centralized SCADA System.
The reports of all these parameters are generated by SCADA.
Total no. of I/Os [no. of parameters] are approx. 500.



PROJECT : TUBE CURING PLANT

FEATURES :
  1. Multi dropping of 7 PLC.
  2. Net based Web enabled reports




SCHEME :
The client has 99 tube curing m/cs(provision of 112 m/cs). When operator produce one tube ,he send a DO in terms of pulse of few msec., it will be pick up by PLC. PLC wil compare the frequency with predefined and increase one respective counter of tube production or false pulse as per logic. The SCADA will collect those all values and generate report accordingly.
Total no. of I/Os [no. of parameters] are approx. 500. 

PROJECT : STATEWIDE WATER TREATMENT AND DISTRIBUTION NETWORK

FEATURES :
  1. Connectivity trough WebServer in between two main location one and two.
  2. Connectivity trough PSTN Network in between head office and main locations.
  3. Connectivity trough GPRS Network in between main location and remote locations.
  4. SCADA and PLC Redundancy.






SCHEME :
THERE ARE TWO MAIN LOCATIONS AS 1 & 2 AND 5 REMOTE LOCATIONS AS R1 TO R5 OF WATER TREATMENT AND DISTRIBUTION.

EACH LOCATION HAS DIFFERENT INSTRUMENTS LIKE FLOW , PRESSURE, LEVEL, TEMPERATURE,PH SENSOR AND ELECTRICAL PARAMETERS WHICH ARE MONITORED AT CENTRALISED LOCATION WITH SCADA.

SCADA SOFTWARE HAS REDUNDANCY FEATURE AS WELL AS IT IS POSSIBLE TO VIEW THE SAME INFORMATION FROM PC SITUATED IN HEAD OFFICE CONNECTED THROUGH PSTN NETWORK

GPRS CONNECTIVITY IS USED FOR ACQUIRING DATA FROM REMOTE LOCATION AT CENTARILSED LOCATIO



Minggu, 06 Maret 2011

9 tips for better industrial SCADA communications

Industrial communications radios connected to I/O modules for supervisory control and data acquisition (SCADA) applications have become faster and smarter and their firmware easier to upgrade. More options and frequencies include 2.4 GHz for short range I/O and 900MHz for long range or for networks that have just a few sites requiring I/O connections, according to Dan Steele, FreeWave Technologies business development executive. Steele spoke at the 30th annual Colorado Rural Water Association Conference on Feb. 16, and he subsequently shared nine tips with CFE Media to improve SCADA-based network communications. 

1) Assess technology options for the SCADA network, identifying needs, goals, and limitations. When it’s time to research technology options, observe what’s available today and what’s going to be available in the future, heeding the “buyer beware” saying. Communication products vary in many ways, and each manufacturer and/or technology has advantages and disadvantages. No single product—and likely not a single manufacturer—can meet all application needs.

2) Reduce costs. While some companies seek to continue to preserve existing investments of wired and wireless technologies, wireless options have clear advantages for SCADA systems. Most obviously wireless installations reduce labor and material costs by avoiding hardwiring remote assets. Speed of deployment adds savings. Wired systems can take days or weeks to be properly installed. Wireless networks generally require only the end points to be installed, saving substantial time and costs. Networks need to scale gracefully as the number of end points increases. After installation savings, scalability is the biggest advantage of wireless over hardwiring, including slow integration into wired systems as it’s implemented.

3) Consider hybrid benefits, tossing out old perceptions. If you need mobile SCADA network access, find somebody that offers it. If you have a microwave tower place, use it. Piggyback slower licensed radio networks with faster 902-928 MHz frequency hopping, AES encrypted networks. Know that you can install IO capable radios (analog and digital signal, 4 to 20 and 1 to 5) to relay contact closures or other data without adding a new PLC or RTU.

4) Maximize SCADA system value. With telemetry technologies, such as spread spectrum radio, the same radio used in remote telemetry units (RTUs) can act as a slave sending data back to the SCADA host, and as a repeater to other field devices or other RTUs. This allows almost limitless network expansion by using remote sites as a series of repeaters, and by using radios in the RTUs to poll the instrumentation. Polling the instrumentation creates a second network reporting wirelessly back to the RTU. This short-haul network is the equivalent of a local area network (LAN).

5) Don’t use a proprietary SCADA system. By using a nonproprietary SCADA system, users gain real-time access, control, and monitoring of their network (including all the devices and functions of their network). They can manage requirements of an ever-growing system allowing them to manage their network in real time with fewer bodies and hours invested. Security and safety improves with better monitoring. For instance, some industrial systems don’t contain a process for monitoring the cathodic integrity for corrosion (like in water/wastewater and oil and gas) to avoid disaster. But with deployment of a wireless system, they can. They can begin by monitoring simple things, such as pump stations at wells, using I/O radios communicating back to the central SCADA system to get up-to-date information on the tanks’ or pipelines’ status. End users can more quickly resolve an emergency wirelessly, instead of manually.

6) Seek SCADA system flexibility. Advanced flexibility of radio communications offers benefits to new SCADA system deployments and upgrades performance of existing SCADA systems. For example, in water/wastewater industrial applications, there need to be generation/distribution, lift stations, system monitoring, and treatment facility systems in place (or planned) to meet the expanding growth of a community’s population and/or service areas to meet future requirements. Each year, many industries deploy more spread spectrum SCADA solutions to help monitor and manage critical infrastructure. Several manufacturers (including FreeWave Technologies) offer spread spectrum radios capable of retrieving data from remote locations. And although wireless IO (input/output) has been available, only recently have both capabilities been offered in one communication solution.

7) SCADA can automate cathodic protection. It is very easy to install an automated cathodic protection system if a company has a SCADA system. However, it is not necessary to have one to implement remote monitoring of cathodic protection. Many companies own and operate their own SCADA network and can leverage their existing capital investment in SCADA through extending the data communication network further to include cathodic protection. For companies that do not currently own a SCADA system, small-scale cathodic protection SCADA systems are implemented with minimal investment in readily available software, off-the-shelf personal computers, and the services of internal or external local integration companies.

8) SCADA systems help the smart grid. As the need for reliable, real-time data communication in mission-critical SCADA systems to monitor and control distribution automation as part of the smart grid continues to increase, electric power utilities seek new and better ways to improve communications infrastructure, adding reliability and security. Broad, integrated solutions can meet the emerging demands in electric power, including frequency hopping spread spectrum (FHSS) serial radios that hop 500 times per second (“he who hops fastest wins”), along with I/O and high throughput Ethernet radios with encryption and easy-to-use interfaces.

9) Seek easy-to-use SCADA software. Field technician or utility operators implementing and using a SCADA network system for data communications want a simplified, rapid setup and easy management of a network. That includes ability to manage multiple frequencies and multiple networks within one system. A centralized storage and management center provides easy access to system configuration and diagnostics data. Technicians in remote or harsh weather environments need robust reporting capabilities. Software like FreeWave’s ToolSuite can manage data communication diagnostics and configuration.


Table: Wireless data comparison
Technology                   Fee      Range               Speed
UHF/VHF                      N         30 mi               9.6 kbps
CDPD                            Y         Limited            19.2 kbps
IEEE 802.11                   N         200 ft             1 1.0 mbps
Spread spectrum             N         >30 mi       115.2 kbps
Bluetooth                        N         50 ft                721 kbps
Licensed                         Y         20 mi               19.2 kbps
Microwave                     ?          Many mi           300,000 km/s   

Source: FreeWave Technologies and Control Engineering

Sabtu, 26 Februari 2011

KEPServerEX v5 OPC and Communications Server Features


KEPServerEX v5 is the next generation of Kepware communications technology and represents over 10 man year's worth of development, delivering both architectural and feature enhancements. KEPServerEX v5 is


the most advanced communication technology and OPC Server on the market and will remain the foundation for future Kepware development. As a result of our new licensing utility, Kepware is providing new vertical driver suites including Building Automation, Oil and Gas, and Water and Waste Water to name a few.

KEPServerEX v5 has been re-designed from the ground up to take advantage of new technology, and is positioned to move onto new automation platforms while delivering legacy compatibility.



Features:

OPC Connection Security

The Secure by Default feature enables users to select whether or not the server should respect the DCOM security settings as they appear in the DCOM Configuration Utility. When this setting is enabled, users can select the authentication, launch and access security requirements through the DCOM Configuration Utility. This allows users to specify the level of security they want to implement and also restrict access for certain users and/or applications.

When this setting is disabled, the server will override the DCOM settings set for the application and will not perform any authentication on the calls received from client applications. It will impersonate the security of the client when performing any actions on behalf of the client application.

Process Mode

KEPServerEX runtime Process features are used to specify how the servers runtime process mode will operate and utilize PC resources. It is used to specify whether the server will be running as System Service or Interactive.

KEPServerEX also allows you to set its own process priority giving the server priority access to resources.

Processor Affinity

This parameter allows the user to specify which CPUs the server can be executed on when it is run on PCs containing more than one.

Host Name Resolution

KEPServerEX allows for host name resolution which is an alias assigned to identify a TCP/IP host or its interfaces. Host names are used in all TCP/IP environments and user can specify host name instead of an IP address when using KEPServerEX v5.

OPC UA (Unified Architecture)


KEPServerEX supports OPC UA Client Connections and the OPC DA data set.

OPC AE (Events)

KEPServerEX exposes event log data (Events) to OPC AE Client applications. The Event server works in runtime and service modes supporting 3 Event categories (Information, Warning, Error). KEPServerEX also supports AE client filtering by event type, severity, and category and is OPC Compliant.





Server Administration Properties

The User Management system of the server controls what actions a user can take within a server project. The User Properties dialog is used to configure the name, password and privileges available for each account.

Multiple Tag Generation Utility

Quickly and dynamically construct multiple tags using the KEPServerEX driver nomenclature. It will allow for a wide variety of address formats such as ranges utilizing hex, octal, decimal, and binary number systems. It will also include the ability to increment the user selected data-type to avoid data overlap.
 Other Features:

  1. Auto Demotion
  2. Automatic Tag Database Generation
  3. Ethernet Encapsulation
  4. Modem Support (PDF)
  5. Application Connectivity
  6. OPC Quick Client
  7. 2 Hour Free Demo
KEPServerEX v5 is designed to allow quick and easy configuration of your communications.




  1. Select a driver to create channel
  2. Specify the device or system to communicate with
  3. Select the items or tags for your database






Evaluation of software: Buying /licensing software development environment

If you are in the buying process of an IEC 61131-3 development environment, there are nowadays a large number of (independent software) suppliers to choose from. To make your selection process easier, the following topics can help you in the evaluation. They are not so much technical details, but additional topics which should be evaluated. 

First: there is no best overall product. A product should meet your needs, which means that you have to evaluate it. Below are some guidelines for it. 

Even if there is a best product nowadays, it can be surpassed with a new release of a competitor. Also, the actual status of the software product itself can be of minor importance: a next version is probably around the corner.

Points of attention:

adaptation costs: how much do they ask to adopt the package to your hardware? How much to include your additional hardware and /or software libraries
the initial costs are different. In most cases the software environment needs adaptations. These can range over a broad area:
the name of the product as appears on the screen
the adaptation to your specific hardware environment
the adaptation of the user manuals to you needs
the creation of user manuals under your own name
the inclusion of additional requirements, like linking to your specific compiler
licensing: besides the initial adaptation costs, licensing can be applicable. How much doe they charge? How much for a one time buy-out? Do the royalties include future updates?
strategy to deal with minor and mayor updates
the quality of the software and training manuals, and there availability in the required languages
is the products itself, including the on line help functions, available in the required languages
support: they all claim it, but who provides it best, and in your language. And at which costs. What is their strategy with respect to dealing with errors, minor and mayor
training: can they provide on-site training for your people. Can they help your users. How does their training manuals look. In which language are they? Can you use their material as basis for your own training?
Update: how do they deal with updates? How do you deal with updates?
does the system provide on-line help? In which languages? Does that cover your needs
is the company financial stable?
which references / installations does the company have? Do they include your competitors? Does that help you? Can you contact some of their references?
how well can the company cope with your future architectures? Do they support distributed systems, if needed?
if you have existing code which you want to include, can they support you? Does the environment support it? How well does it match? How much effort is estimated by them and by you to do the job? Are they willing to do it (at fixed costs), showing confidence and giving you a guarantee? At which costs? Which time frmae
can they provide an evaluation package?
how fast are they in their response?
do they speak your language, not only in your home language, but also do they know your environment?
is the product certified by PLCopen? At which level? For which language? How many updates after their certificate? Can they show (a copy of) the certificate?
can they provide a compliance statement by sending the IEC 61131-3 feature tables showing clearly what they support?
what are your main (expected) programming languages for this environment? How long are these languages supported? Which release are they on?

Remember: you don't want to be the guinea pig: testing takes time and costs money. 

A good way to get started:

  1. describe your (initial) requirements clearly on paper, including quotation procedure and deadline
  2. send to all potential suppliers, minimal 5, preferably on the same day (fax)
  3. note when the quotations get in, giving you a first impression of response speed
  4. compare the overall quality of the offer
  5. compare the fulfilment of your requirements
  6. check the differences
  7. talk to at least 3 companies
IEC 61131-3 (PLC Programming Languages)
This document is a compilation of responses by the Experts of IEC TC65B/WG7/TF3 task force to Frequently Asked Questions (FAQs) about the IEC Standard 61131-3. The contents of this document are not normative and do not form a part of the Standard. 



Will IEC 61131-3 reduce the innovation of new languages and concepts for PLCs? The main objective of IEC 61131-3 has been to standardise existing PLC languages. There is no intention that IEC 61131-3 should reduce the development of new PLC languages. Any PLC vendor is free to provide extensions and additional languages where required. Because the standard allows proprietary function blocks to be programmed in non IEC 61131-3 languages such as C++, it always possible to provide extensions fairly 'seamlessly' e.g. packaged as function blocks. This is well demonstrated by IEC 61131-7 "Fuzzy control programming" which defines language extensions for implementing fuzzy logic encapsulated as function blocks.


Why does IEC 61131-3 have 'resources'? Is a resource just another name for a PLC? A resource is a general name for anything that is able to provide the appropriate access to I/O and services to allow IEC 61131-3 programs to execute. Normally a PLC that can execute IEC 61131-3 programs can be regarded as a single resource. However, other processors, such as a personal computer (PC) if able to support the execution of IEC 61131-3 programs may also be regarded as resources.
IEC 61131-3 seems to be very complicated. Is it still possible to create simple Ladder programs by users unfamiliar with IEC 61131-3?  An IEC 61131-3 system can still be programmed as a single Ladder program if required. Programming systems may provide a option to create a simple IEC 61131-3 configuration containing one resource, one task, and one program instance of a program type. All of this could be created automatically so the user is only concerned with developing a single ladder program. Function blocks and other IEC 61131-3 constructs do not need to be used.
Will IEC 61131-3 languages result in applications that run more slowly and require more memory than using simple ladder? Attempting to implement IEC 61131-3 constructs such as function blocks on PLCs that were originally only designed to support ladder programs, will inevitably have performance and memory overheads. PLCs specifically designed with firmware to support the execution of IEC 61131-3 programs should not be noticeably slower than classical ladder based PLCs. The improvements in software structure from IEC 61131-3 should allow users to be able to write more efficient applications that will be significantly easier to maintain than monolithic ladder programs.
Is it really possible to port IEC 61131-3 software from one vendor's PLC to another? possible No it is not simply to take an application that runs on one type of PLC and copy it over to another type. There are several problems preventing the direct porting of IEC 61131-3 software.
  1. The PLC I/O systems use different addressing schemes.
  2. The task scan rates supported on different PLCs vary.
  3. Each PLC vendor may have implemented a different sub-set of IEC 61131-3 features.
  4. Similarly each vendor may have different values for implementation specific parameters such as maximum array sizes, string lengths etc.
  5. Finally there is not a standard file format in which to store and port IEC 61131-3 applications.
Notwithstanding these constraints, at the function and function block level, it may be possible to re-implement identical POUs on different vendors PLCs. Textual source code for POUs developed in ST or IL can be ported between different types of PLCs.
Is it possible to automatically convert between IEC 61131-3 languages, for example, can a POU written using LD be viewed and edited in ST or FBD? This is a favourite IEC 61131-3 myth. There has never been any intention that it should be possible to convert any language into any other language. If a restricted sub-set of each language is used some limited portability may be possible but there are some significant problems. For example, there is no way to represent expressions involving array variables in the FBD language.
Can function blocks also have execution control variables EN and ENO, like functions?  The standard is not explicit about whether function blocks may have execution control variables, e.g. for connecting function blocks within ladder rungs. However, from the IEC 1131 languages user guidelines, (part 8 of the IEC 61131 standard), it is implied that for consistency, both functions and function blocks should use EN and ENO variables for execution control in ladder diagrams. It is an implementation decision whether function blocks have EN and ENO variables that can be used in the FBD language for explicit execution control. This may be useful in eliminating execution order ambiguities that might arise in FBD networks.
In a full graphic implementation of FBD, is there anyway to distinguish between lines that cross-over and lines that join. The graphical format of lines, cross-overs and junctions in full graphics implementations of languages LD, FDB and SFC is not specified in IEC 61131-3. It is a implementation decision outside the scope of the standard how fine graphic details such a line cross-overs are depicted.
Where are type definitions actually defined and what is their scope? All type definitions for datatypes and POUs can be regarded as outside the entire IEC 61131-3 configuration and apply to all entities within the configuration, i.e. all type definitions have global scope. This is as if all type definitions exist in a conceptual 'header file' that is pre-processed before any entity within a configuration is compiled. Extensions to IEC 61131-3 are now being considered to provide a more flexible range of type scopes. With large applications, more specific type scopes may be necessary, such as, a library scope for type definitions that only apply to POUs within a specific library.
Do IEC 61131-3 languages enforce data type consistency? All IEC 61131-3 languages except IL, enforce strict data type consistency, i.e. it is not possible to directly assign (or connect) variables of one data type to variables of different data types. Data type conversion functions are necessary to convert the values of variables to the appropriate type, e.g. an INT value should be converted to a REAL before being assigned to a REAL variable. In the IL language, it is not always possible for a compiler to check that the type of value in the accumulator will match the data type of any variable to be loaded from the accumulator. With IL, run-time checks are required to ensure data type consistency.
When are the actions in an SFC actually executed? Every SFC is encapsulated in a function block or program POU. When the POU is invoked, e.g. because it has been scheduled by a task, the contained SFC is evaluated once, i.e.
The current set of active steps is determined.
All transitions associated with active steps are evaluated
Actions which nominally ceased execution in the previous SFC evaluation ( because their Q flag has been cleared ) are executed one last time.
All actions that are active are executed once.
Any active steps that precede transition conditions that are true are deactivated and their succeeding steps are activated.
The encapsulating POU should be repeatedly invoked for the SFC to progress through its various steps.
How can the execution of all actions in an SFC be halted and the SFC restarted? The execution of all actions in an SFC can be halted by suspending the invocation of the encapsulating POU, see When are the actions in an SFC actually executed? If, at a later time, the POU is again repeatedly invoked, the active actions in the contained SFC will continue to be executed. The only way to re-start an SFC from its initial step and clear all active actions is for the resource containing the POU to have a 'cold start'. A jump back to the initial step is always possible using an explicit branch, e.g. back from the last step in a sequence. However, this cannot guarantee to clear any stored actions or simultaneous sequences which may be been started.
Can more than one variable be fixed at the same direct address using the AT construct? The standard does not forbid this. Allowing variables to be at the same or to use overlapping memory locations is an implementation issue. This however may invalidate data type consistency - see Do IEC 61131-3 languages enforce data type consistency?.
When using the AT attribute, does the size of a memory location specified by a direct address have to match the size of the variable? The standard is unclear; there are two ways of interpreting the purpose of the direct address. It either specifies a) the actual memory location, in which case the location size and variable type size should match or b) the starting address from which the variable will be located, in which case sizes do not need to match.
When are user specified initialisation values for variables used? User specified initial values apply to non-retentive variables both at "cold restart" and "warm restart", but they only apply to retentive variables at "cold restart". On "warm restart" retentive variables have the same values as existed when their resource stopped executing, e.g. due to a power outage. The 61131-3 amendment allows initialisation values defined by the VAR_CONFIG construct to override type specific initial values. Therefore, VAR_CONFIG specified initial values apply at "cold restart" or "warm restart" for non-retentive variables, and to "cold restart" for retentive variables.
Can function block instances be passed as inputs to other blocks?  Yes if function block FB1 is passed as an input to a second function block FB2, it is possible to invoke the function block FB1 within the body of FB2. Any input parameters of FB1 not defined in the invocation call within FB2 will take values defined by earlier invocations of FB1 made outside of FB2. Function block instances should be passed as VAR_IN_OUT parameters otherwise the values produced within the internal invocation will not be preserved.
Are the assignments of inputs and outputs to programs at the resource level fixed or can they change dynamically? They are fixed. Programs are the highest level IEC 61131-3 programmable organisation unit. It is not possible to have language statements outside of a program. In a resource declaration it is only possible to assign input and output variables to the program interface. If it is necessary to change the inputs used by part of a program, then all inputs concerned should be passed to the program and any dynamic selection of particular inputs should be done within the program body, e.g. to switch between using two different sets of sensors.