Chelsfield Consultants SOFTWARE APPLICATIONS








HOME SERVICES TELECOMMUNICATIONS SOFTWARE HARDWARE FAQ CONTACT	SITE MAP


Whilst communication control standards are now emerging, these tend to be low-level protocols, rather than application standards that are so often required. Getting everything to co-operate on a network can be very complex. We can help by creating custom software to glue your process machinery together exactly as needed. ... more


Process instrumentation is about knowing what’s going on and reacting fast enough. Accurate intelligence and clear reporting are essential. If you think there is room for improvement in your plant, we’d be happy to conduct an audit. Why not give us a call and arrange an initial informal chat. We’d be happy to talk to you without cost or any obligation.

Writing software to integrate systems may be all that's required, but what if hardware needs changing. Software can only go so far. We can identify and design hardware solutions too, this usually presents no difficulty for us. Chelsfield is as much about hardware design as software implementation. In fact the two disciplines are naturally interwoven and we’re equally comfortable with both.

The general perception that custom software costs are prohibitively high is perhaps based on the failure of a few high-profile cases in the media. Understandably then there are bound to be numerous questions such as:


	How long will it realistically take to write?
	How can I be sure it will work as specified?
	How is it to be maintained, can we do this?
	How long will it take to test and deploy?
	What about training - how much does this cost?
	Will it still work if we update our computer system?
	How much does it cost, what are the real benefits?

Click here for a GENERAL OVERVIEW, and some answers to these questions. Additionally, please contact us direct to discuss your requirements in more depth. We've been writing industrial software for over 30 years, why not give us a call and see how you can improve the data flow in your plant.

The diagram shows a typical factory scenario. Over time various control and monitoring instruments have been added. Most of these devices now come complete with their own control software, are able to connect to a LAN and can talk to other devices, usually via some non LAN based protocol - Typically an RS232 or RS422 serial link.

Even if you're replacing your older legacy devices with LAN based systems this invariably still leaves a gap in interconnection between instrumentation systems. In most situations several applications still have to be run in parallel whilst switching between them, extracting the data as you go. Sound familiar?

Ironically, the more instrumentation is added the more one tends to move away from the ideal of central plant monitoring. The data on the resultant patchwork of connections becomes ever more transparent to process operators as system complexity increases

By comparison, the diagram on the right passes all important data through a central system controller. This is done by the technique of Distributed Intelligence computing that employs remote data acquisition and control units (RDU). Each RDU can be programmed to mimic any I/O function. All data is now LAN based and can be used in real time.

The advantages are clear, instant correlation of data, access to instrument control from any point in the network and standardised modeling though software carrying only the functions and facilities needed.

Two basic type of RDU are available. The only difference between them is essentially the data transfer rate required and the degree of pre-processing of data required. Type i is the lighter weight version based on an 8051 CPU core running at 48Mhz. The second is based around a low power AMD device running at 500Mhz.



	REMOTE DATA UNIT
TYPICAL CONTROLLER

Chelsfield has developed the concept of Distributed Computing Systems. These have been applied in a wide variety of situations, principally where some kind of data acquisition or control function is required over a large area.

D.I. Systems are based around a dedicated central computer usually termed a controller. This device communicates over the LAN to any given set of Remote Data and Control Units.

Fundamentally the hardware of an RDU is flexible enough to satisfy a very wide range of I/O functions. This includes driving printers, display and keyboard devices, communicating with UARTS and modems.

The function set of any particular RDU is defined by it's physical I/O configuration and it's programming which may be stored in non-volatile RAM or FPGA's or reside in, EEPROM, EPROM as part of the firmware.

The picture (left) shows a typical controller and an RDU device. Data units are small and can be wall mounted. The number of devices attached to the system is arbitrary and will vary with things such as cable routes and lead length to sensors etc. The diagram of an RDU essentially shows how the device is connected. Note that two generic CPU processors are given, either type may be used depending on the application, the data throughput, and degree of pre-processing required.

If the requirement is for security, simple data acquisition (analogue or digital) then the 8051 option may be best. For on-board DSP and higher volumes of traffic, including the driving of colour video displays then the more powerful processor will be required.

D.I. SYSTEM FEATURES

	D.I systems can provide complete correlation of signals
	RDU devices have autonomous and asynchronous operation
	Increase in system computing power when an RDU is added
	Can communicate directly with each other over the LAN
	Can be interrogated from any LAN terminal
	Can satisfy the requirements of safety critical environments
	Can monitor or watchdog each other