Why Industrial Automation Controllers are not catching up processor technology advancements? I worked on a project where we attempted to develop a new controller with the aim to maximize the use of Open Source/COTS based components.
Many a times we debated on 96 MHz big endian processor and the operating system, Linux which we chose for this project.
Many players in the market still use a typical board with a 100 MHz processor.
Of course with industry standard compliance list like EMC, ESD, RF, Surge, Power etc. and stringent temperature (-40 to +70 degrees Celsius) and relative humidity requirements. And most importantly the heat dissipation factor which may cause the need of a fan.
What is that operating system which can meet all demands of a real-time controller.
Currently industry uses VXWorks, Nucleus PLUS, VRTX and recently some flavors of Linux like Monta Vista, RT-Linux. Of course there are so many proprietary custom made operating systems.
How do we boot the board? Traditionally it is done using TFTP boot. A TFTP server runs on a work station and is expected to be ON while the controllers are booting up. And applications are built to take the complete image while comprised of kernel, control engine, custom network stacks, process control applications etc.
Some controllers use on board flash to store boot code and kernel and basic services to receive and execute control applications. Recent hardware designs are done considering more on board flash, typically ranging from 4 MB to 64 MB. These boards got more RAM also, typically in the range of 16MB to 128MB.
Apart from this external compact flash interfaces are adding storage options to controller.
Hi speed compact flashes or micro drives can be added as per requirement. However the disadvantage here is number of read/write cycles and kind of hardware interface (parallel/PCMCIA etc.).
And newer boards are coming up with 100 Mega bits per seconds Ethernet controllers.
Of course it is needed because all most all IO networks of today got Ethernet variants.
With the addition/enhancements of these peripherals the CPU performance demands are increasing dramatically. More storage options and high speed Ethernet access added new challenges like bulk data management and faster memory access. More and more functional requirements are now met on controllers itself using embedded web servers, embedded databases and time synchronization modules.
But are these CPU’s, with their resources being managed by RTOS, capable enough to meet the real time demands without effecting basic operations like IO scanning, control execution and hardware monitoring tasks?
Recently the demand for thin but service rich operating systems is growing. Security is one more aspect that adds heavy computing routines to basic operating tasks list. Firewalls are part of controller design now. Embedded databases and NFS partitions are commonly used by many controllers for non critical storage purposes.
Advanced power management, online upgrade and Ethernet based mirroring demands more computing resources out of modern controllers.
I would like to do some detailed study on this. Are there any good links for this.
[The views expressed on this website/blog are mine alone and do not necessarily reflect the views of my employer.]
Tuesday, January 24, 2006
Saturday, September 03, 2005
Modbus TCP simulator
I got a requirement to develop a Modbus TCP simulator.
Thought of doing something quickly using VB6. Then ended up with limitaion of good threading library. Then thought of doing in VB.Net. Coded using MsFlexGrid controls. Found them looking very nice. All working fine for 15 minutes. Suddenly there is a red cross across the Grid. After 10 minutes another grid got the same. Then observed Microsoft already accepted that bug and I need to hunt for a patch to fix it. Left that option too.
Then thought of doing in VC6 using MFC Dialog. Another problem, I want to simulate 64 AI, 64 AO, 64 DO and 64 DI. So thought of using text boxes for AI and AO and CheckBoxes for DI and DO. Another limitation, I cant have more than 255 controls on a Dialog box. As all frames are inherited from Dialog boxes no option left.
Then decided to use VB UI and VC library. I am more biased towards pthread library (ftp://sources.redhat.com/pub/pthreads-win32) than Windows. Just decided to use Win API instead of going through big loop of ATL and COM stuff.
Interesting I got good working Simulator. Its not complete but easy to enhance.
I have VB6 application which essentially has code to export handles of controls to vc library.
Thought of doing something quickly using VB6. Then ended up with limitaion of good threading library. Then thought of doing in VB.Net. Coded using MsFlexGrid controls. Found them looking very nice. All working fine for 15 minutes. Suddenly there is a red cross across the Grid. After 10 minutes another grid got the same. Then observed Microsoft already accepted that bug and I need to hunt for a patch to fix it. Left that option too.
Then thought of doing in VC6 using MFC Dialog. Another problem, I want to simulate 64 AI, 64 AO, 64 DO and 64 DI. So thought of using text boxes for AI and AO and CheckBoxes for DI and DO. Another limitation, I cant have more than 255 controls on a Dialog box. As all frames are inherited from Dialog boxes no option left.
Then decided to use VB UI and VC library. I am more biased towards pthread library (ftp://sources.redhat.com/pub/pthreads-win32) than Windows. Just decided to use Win API instead of going through big loop of ATL and COM stuff.
Interesting I got good working Simulator. Its not complete but easy to enhance.
I have VB6 application which essentially has code to export handles of controls to vc library.
Nice Coding practice for byte packing
I am trying to write a code to using SOCK_RAW using PACKET protocol family PF_PACKET.
My intention to find out healthiness of Target with minimum overhead. Instead of trying to call connect i want to use ICMP protocols like ping. While doing that i thought why cant I do event ARP. Then started looking for some sample code for ARP.
I found Blacky Room at fdin. He got simple codes for lower level Ethernet Protocols. Ofcourse the site is in Japanese language. But can access code samples.
One good thing i liked at these code samples is the way packing of bytes is done before calling send. In the following function , buffer is a character array. And eth and arp are just pointers.
Iinitially these pointers are just addressed to respective positions. Then as members are filled buffer is ready.
Normally i do other way around. First i update structures and then assign to each byte of buffer like buf[0] = arp->arp_hrd.
But this method essentially eliminates second copy and more secure.
My intention to find out healthiness of Target with minimum overhead. Instead of trying to call connect i want to use ICMP protocols like ping. While doing that i thought why cant I do event ARP. Then started looking for some sample code for ARP.
I found Blacky Room at fdin. He got simple codes for lower level Ethernet Protocols. Ofcourse the site is in Japanese language. But can access code samples.
One good thing i liked at these code samples is the way packing of bytes is done before calling send. In the following function , buffer is a character array. And eth and arp are just pointers.
Iinitially these pointers are just addressed to respective positions. Then as members are filled buffer is ready.
Normally i do other way around. First i update structures and then assign to each byte of buffer like buf[0] = arp->arp_hrd.
But this method essentially eliminates second copy and more secure.
int send_arprequest(int sock, struct dev *dev, struct addr *src, struct addr *dst)
{
struct sockaddr_ll sll;
struct ether_header *eth;
struct ether_arp *arp;
char buf[sizeof(struct ether_header) + sizeof(struct ether_arp)];
memset(&sll, 0, sizeof(sll));
sll.sll_family = PF_PACKET;
sll.sll_ifindex = dev->index;
sll.sll_halen = ETH_ALEN;
memcpy(&sll.sll_addr, dst->mac, ETH_ALEN);
memset(buf, 0, sizeof(buf));
eth = (struct ether_header *)buf;
arp = (struct ether_arp *)((char *)eth + sizeof(struct ether_header));
/* arp header */
arp->arp_hrd = htons(ARPHRD_ETHER);
arp->arp_pro = htons(ETH_P_IP);
arp->arp_hln = ETH_ALEN;
arp->arp_pln = IP_LEN;
arp->arp_op = htons(ARPOP_REQUEST);
memcpy(arp->arp_sha, src->mac, ETH_ALEN);
memcpy(arp->arp_spa, &(src->ip), IP_LEN);
memset(arp->arp_tha, 0, ETH_ALEN);
memcpy(arp->arp_tpa, &(dst->ip), IP_LEN);
/* ether_header */
memcpy(eth->ether_shost, src->mac, ETH_ALEN);
memcpy(eth->ether_dhost, dst->mac, ETH_ALEN);
eth->ether_type = htons(ETH_P_ARP);
/* send to arp request packet */
return sendto(sock, buf, sizeof(buf), 0, (struct sockaddr *)&sll, sizeof(sll));
}
Friday, April 15, 2005
Can we expect rich editors for 61131-3 using XML schemas
plcopen TC6 XML- schemas are ready. More or less everyone follows XML schemas now.
Isagraf claims XML usage in their new release 4.5 .
One definite advantage of using XML schemas for 61131-3 representation is seamless integration of all five languages. Also better export and import features.
Ofcourse there are some other advantages also. But most of them cant make a new impression to users (control programmers). These representation remain at back end.
I feel neutral characteristic of XML can also be capitalized here. In today's world most of the configurators generate target independent code and launch virtual machines on target to make up control application.
I guess now the need comes to build platform independent configurators. Also ability to view control programs over web using the power of XML and style sheets. Probably browsers can be used to monitor online , modify/force variables and to do minor modifications if schema permits.
can we expect rich editors for 61131-3 using these XML schemas...!!!!
Isagraf claims XML usage in their new release 4.5 .
One definite advantage of using XML schemas for 61131-3 representation is seamless integration of all five languages. Also better export and import features.
Ofcourse there are some other advantages also. But most of them cant make a new impression to users (control programmers). These representation remain at back end.
I feel neutral characteristic of XML can also be capitalized here. In today's world most of the configurators generate target independent code and launch virtual machines on target to make up control application.
I guess now the need comes to build platform independent configurators. Also ability to view control programs over web using the power of XML and style sheets. Probably browsers can be used to monitor online , modify/force variables and to do minor modifications if schema permits.
can we expect rich editors for 61131-3 using these XML schemas...!!!!
Wednesday, April 13, 2005
Ethernet TCP/IP as control/neutral network
I was going through March edition of InTech. Articles Wide terrain in LAN by Kevin and Roland & Dream come true or nightmare? by William have potential scope for discussion.
I guess , in instrumentation and Automation world , hunt for a better network never stops. We try to have a network that is reliable , redundant , light (minimum message overhead), neutral , open , fast , cheap etc..etc.. Recommendations and restrictions are there for every cause like interference , collision , optimised routing , quick recovery , open , security etc.. Industry developed so many proprietary networks and applications by spending expensive resources. But when trend started to make things on open standards , Ethernet TCP/IP stood as best option. On the other hand field bus technologies like Profibus , FF etc and neutral applications like OPC cropped up. Later on to bring field buses onto plant network TCP/IP extensions demanded MODBUS over TCP/IP , PROFINET , HSE Ethernet/IP etc.. At some other corner a new dish by name wireless is getting prepared.
so the result is industrial networks are on IEEE x802.xx race... RACE is ON , who is going to Win?
I guess , in instrumentation and Automation world , hunt for a better network never stops. We try to have a network that is reliable , redundant , light (minimum message overhead), neutral , open , fast , cheap etc..etc.. Recommendations and restrictions are there for every cause like interference , collision , optimised routing , quick recovery , open , security etc.. Industry developed so many proprietary networks and applications by spending expensive resources. But when trend started to make things on open standards , Ethernet TCP/IP stood as best option. On the other hand field bus technologies like Profibus , FF etc and neutral applications like OPC cropped up. Later on to bring field buses onto plant network TCP/IP extensions demanded MODBUS over TCP/IP , PROFINET , HSE Ethernet/IP etc.. At some other corner a new dish by name wireless is getting prepared.
so the result is industrial networks are on IEEE x802.xx race... RACE is ON , who is going to Win?
Are there any blogs on Industrial Automation
I tried to search for blogs about industrial automation experiences and knowledge sharing.
Somehow they are not very lively. Some one started a few but discontinued.
I have spent seven years of my professional life in this domain and still continuing with this.
Felt like starting one another with the only intention to keep it live as long as I can.
here i am ...
Somehow they are not very lively. Some one started a few but discontinued.
I have spent seven years of my professional life in this domain and still continuing with this.
Felt like starting one another with the only intention to keep it live as long as I can.
here i am ...
Friday, November 12, 2004
Subscribe to:
Posts (Atom)