CSWorks - FAQ

Frequently Asked Questions

General

Q. Was CSWorks designed for any particular industry?

A. No. CSWorks is just a framework that performs data exchange between data sources and UI components. There is no limitation on area of use, CSWorks can be a good fit for any kind of process control: building automation, water and wastewater, factory automation, oil & gas, you name it.

Q. What is the projected downtime?

A. Downtime caused by system failures, upgrades and re-configuration can be eliminated by using functional redundancy (mirrored servers). Data loss can be eliminated by using data redundancy (fail-safe database). In a non-redundant deployment, downtime caused by system upgrades and re-configuration is minimal - it's just a matter of 5-30 seconds for restarting a service.

Q. Can CSWorks server components run on virtual machines?

A. Absolutely.

Q. I have an existing HMI/SCADA solution, and want to convert it to CSWorks. Is a conversion tool available?

A. There are no out-of-the-box conversion tools, but in most cases, it is possible to create a tool/script that performs this kind of conversion. Since CSWorks client HMI screen is just a regular Silverlight application, developers do not have to deal with any proprietary file formats or interfaces.

Q. How do I perform CSWorks troubleshooting?

A. In most cases, tracing will give you the answer. Please read about CSWorks tracing in this blog posting.

Q. I have installed CSWorks, but I don't see any graphics designer tool. How am I supposed to create my client UI? I just want to create a screen, drag-n-drop some controls, bind them to data sources and run my application in minutes!

A. Starting from version 1.4, you can do that. CSWorks setup integrates CSWorks client components into Microsoft Visual Studio 2010 development environment, so developing a CSWorks client application is all about drag-n-dropping controls from toolbox, arranging them, binding them to data using "Properties" panel. In some cases, manual XAML editing is involved.

Architecture

Q. How CSWorks transfers data from server to client? What kind of latency should be expected?

A. CSWorks uses pull data transfer model: CSWorks clients query CSWorks server components for data updates periodically, data update rate can be configured on the client side. CSWorks LiveData Server gets data from data sources, data update rate can be configured for every data source individually. Under normal circumstances (network is not congested, server CPU load is not high, no memory swapping) the maximum latency can be calculated as follows: Data source to server update rate + Server to client update rate

Q. I am planning to build a hosted (on-demand) solution shared by multiple customers. Can I use CSWorks?

A. CSWorks redundancy and partitioning capabilities, open architecture and web-readiness make it a perfect candidate for a hosted solution environment. But you have to plan your data access rights management very carefully. Please see CSWorks documentation for details.

Q. What if some of my data sources (OPC servers) are unstable? Will it affect other data sources?

A. If some data sources become unavailable, CSWorks LiveData Service waits for some time and re-connects to them. Other (healthy) data sources should not be affected in any way.

Q. Does CSWorks support web load-balancing?

A. Absolutely. Web service layer was designed with web farm scenario in mind.

Q. Does CSWorks offer functional redundancy? Data redundancy?

A. You can configure mirrored CSWorks server components for functional redundancy, see CSWorks documentation for details. CSWorks does not provide data redundancy out-of-the-box, you will have to use your database redundancy capabilities (mirroring, clustering, replication etc).

Q. I think that pull model is outdated and suboptimal. Can I use push model? What about WCF duplex communications? HTML5? Web sockets?

A. When properly designed, pull model gives pretty small latency and unparalleled robustness. But the most important fact is that old-style, port 80, HTTP- based communication works virtually across any firewall without any additional administration/hardware/software overhead. At the moment, there are no plans to use any of the mentioned technologies until they become the de-facto standard.

Q. What ports does CSWorks use?

A. All port settings are configurable. By default CSWorks uses: - port 80 for client-server HTTP communication; - port 8087 for LiveData Service WCF communication; - port 8088 for Alarm Service WCF communication.

Features

Q. What hardware/software platforms are supported?

A. On the server side, CSWorks runs on Windows XP, Vista, Windows 7, Windows Server 2003, Windows Server 2008. On the client side, it runs on any computer that is capable of running Microsoft Silverlight 4 and its flavours. At the moment, the list includes only desktop versions of Microsoft Windows, Mac OS X and Windows Phone 7.

Q. What database engines can I use to store Alarm and Historical data? What database engines can I use as data source?

A. The short answer is: any SQL database that has .NET data access provider. CSWorks was thoroughly tested with SQLServer, SQLite, Oracle, mySQL and PostgreSQL data access providers. Also, CSWorks may work with ODBC data sources. If you are trying to use CSWorks with another kind of SQL database and are having problems, please let us know, we will be happy to assist. Keep in mind though: only scalable, server-oriented SQL databases. For example, data acquisition from Microsoft Access through ODBC is possible in theory, but hardly viable in practice due to Microsoft Access limitations.

Q. Does it work across firewalls?

A. If you mean client-server communication, absolutely. CSWorks was designed with this scenario in mind. If you have a complicated CSWorks deployment with multiple server components running in different networks, things are a bit more complicated but manageable. It's a matter of configuring WCF (Windows Communication Foundation) communication between CSWorks server component, and this is not a CSWorks realm actually - it's all about WCF transport configuration.

Q. I/O data scaling support?

A. Yes, starting from version 1.2.3800. For historical data, use expressions. For live data items and live data trending, use ScaleFactor attribute.

Q. What version of OPC DA is supported?

A. CSWorks can use any OPC DA 2.05 server as data source.

Q. Does CSWorks have support for OPC AE? HDA? OPC UA?

A. CSWorks does not use OPC AE or OPC HDA because Alarm Service and History Recorder rely heavily on CSWorks LiveData Service architecture. Using OPC UA data access as data source is possible in theory, but was not implemented due to the lack of interest from the customers.

Q. Can I get data updates from CSWorks LiveData Service through OPC DA and alarm information from CSWorks Alarm Service through OPC AE?

A. Unfortunately, no. If you have any interest in implementing OPC servers for CSWorks LiveData and Alarming, we will be happy to provide advice and guidance.

Setup and configuration

Q. What are the installation prerequisites?

A. CSWorks client applications run on any computer that is capable of running Microsoft Silverlight 4. CSWorks Server components require .NET 4.0, IIS (Internet Information Services) and ASP.NET. To develop CSWorks application, you will need Microsoft VisualStudio 2010, Microsoft Expression Blend 4, or Microsoft Visual Web Developer 2010 Express (available for free at Microsoft website).

Q. I do not have IIS installed and I have no possibility or desire to install it. Can I give CSWorks a try?

A. Yes. Your download email contains a link to CSWorks Light - CSWorks distribution that does not require IIS and uses Microsoft Cassini web server instead. This distribution is for demo purposes only and should not be used in production environment. For more details see this blog posting. Keep in mind though: if you ever want to run a web-based HMI/SCADA/M2M on Microsoft stack of technologies, you will have to deal with IIS anyways.

Q. Can CSWorks web service components run on Linux/Apache?

A. Unfortunately, no.

Q. I want to try CSWorks, but I am new to web application development and I don't know how to configure IIS and ASP.NET. Please help!

A. There is a quick guide on IIS/ASP.NET configuration in this blog posting.

Q. When running CSWorks setup, I am getting an error.

A. Most of the times, it's an IIS/ASP.NET-related issue. See blog postings marked with "setup" tag, they may give you some clues.

Q. I have installed CSWorks, and I can see demos working. I want to learn how CSWorks and I want CSWorks demo applications to use my OPC server. I cannot make CSWorks connect my OPC server, I am getting errors.

A. Most of the times, the problem is OPC server security. See "CSWorks demo and your OPC data source" guide, it probably has the answer.

Q. I use CSWorks server redundancy capabilities and web farm for hosting CSWorks web services. Does CSWorks synchronize configuration files on different servers?

A. No, it does not. Use file synchronization tool or solution of your choice to keep CSWorks configuration files in sync.

Q. Is there a configuration tool for CSWorks?

A. At the moment, there is no such tool. All CSWorks components are configured using XML-based files. Use text or XML editor of your choice to change CSWorks configuration.

Q. Can IIS host CSWorks web server components as a 32-bit application on a 64-bit OS?

A. This is not a common scenario, and there is no easy way to do that. CSWorks 64-bit web server components will not run in 32-bit mode (you may find some details in this blog post). On the other hand, CSWorks 32-bit setup that installs 32-bit web server components will not install anything on a 64-bit machine. The only workaround is to manually copy CSWorks 32-bit web server components from a 32-bit installation to the 64-bit machine and configure them manually.

Customization

Q. Operators need personalized UI: colors, pens in trend controls, alarm event filtering etc. Is it supported? Can they store and re-use their favourite configurations?

A. Yes. Complex client-side components like Alarm Summary and Trend Control allow users to customize their working environment, save, and re-use their settings. For HMI screens that use simple UI elements (pipes, buttons, gauges etc) this customization can be implemented by application developers.

Q. My customers want to see messages in their native language and dates/numbers in their native language format. Is it possible?

A. Absolutely. All dates and number formats in CSWorks client honour culture settings. Alarm Summary and Trend Control use localized strings. Read about CSWorks internationalization in this blog posting.

Q. We need a special mode for color-blind operators. We also need a special mode with larger fonts. Is this supported?

A. At the moment, there is no out-of-the-box support for on-the-fly skin changing. But this is something that can be done by application developers.

Performance and limitations

Q. How many I/O points can I have in my deployment? How many I/O point updates per second can I get?

A. The number of I/O points is virtually unlimited, because you can keep adding more and more LiveData Servers. As for the updates per second, the answer is: it depends on the computing power of LiveData Server and network bandwidth available for communication. For example, in our lab, CSWorks LiveData Service running on a Core 2 Duo, 2GB RAM server did not have any problems processing 80,000 tag updates per second.

Q. How many alarms can I have in my deployment?

A. Maximum number of alarms is limited by the number of alarm servers in the deployment and network bandwidth. For a single-server case, you may find some performance statistics in this blog posting.

Q. How many historical data points can I have in my deployment?

A. Maximum number of historical data points is limited only by number of History Recorders in the deployment, network bandwidth and historical database capacity. Please see this post for some History Recorder performance statistics.

Q. How many LiveData items can I monitor from a single HMI screen?

A. The number of data items on the screen is not that important. What is really important is the number of data item updates per second. Every data item update requires some network bandwidth to be delivered to the client and some client CPU resources to reflect the change on the user's screen. On a screen without complex animation and other visual effects, hundreds of changes per second should not be a problem on modern desktops.

Q. What are the network bandwidth requirements?

A. You will have to calculate it yourself. Here are some basic estimates: - a single LiveData update takes about 40 bytes; - a single alarm event takes about 150 bytes (see this blog posting about alarming performance); - a single historical observation takes about 90 bytes (see this blog posting about trending client performance).

Security

Q. Can I use SSL to secure CSWorks client-server communication?

A. Absolutely. Please see CSWorks documentation for details.

Q. My CSWorks deployment includes geographically distributed server components that communicate through unsecured public channels. Are there any options besides VPN?

A. Yes. All CSWorks server components communicate through WCF (Windows Communication Foundation). WCF offers multiple ways to secure communications. Please see WCF documentation for details.

Q. We are building a complex solution that involves access rights management. What CSWorks has to offer?

A. CSWorks can enforce live data, alarm or historical data access authorization. Application developer must implement rights management infrastructure that should inform CSWorks web service layer about specific operations that current user can perform. CSWorks web service layer makes sure that a user does not go beyond the set of privileges he or she has been granted. Please see CSWorks documentation for details.

Alarming

Q. Can I suppress some alarms on system startup/shutdown?

A. Yes. Use deployment variables in Alarms.xml. Please see CSWorks documentation for details.

Q. Can I configure alarm priority levels? CSWorks demo has Low, Medium and so on, but I need it to be LOW (yellow) and HIGH (red). What CSWorks has to offer?

A. Alarm priority levels (and colors) are configurable through Alarms.xml. Please see CSWorks documentation for details.

Q. Operators need a possibility to subscribe only to specific alarms. Is this supported?

A. Yes. See Alarms->Subscribe menu in Alarm Summary.

Q. We need alarm distribution by pager, RSS and voice mail. Is that supported?

A. There is no out-of-the-box support for advanced alarm distribution besides 2-way SMS and email notification, but developers can add this functionality in their custom server components. Please see Alarm Agent demo applications to learn how this can be done.