It has been a pleasure and fantastic experience being a control system developer for the past 4 years and I feel good in sharing my thought on reducing overheads in control system software development.
This could very well fit as a design proposal write-up, but would certainly do a heap of positive impact on Software Developers, Designers & Architects who experience the hardness in rewriting code to cope up with fast growing Semi Equipment industry.
I shall give a picture on the challenge that is currently present with regard to Semi hardware obsolescence or Hardware upgrade, followed by my solution and idea to handle these challenges.
I believe I have set a right expectation and a valid reason to read my Blog J .
The components in an Equipment (Any Semiconductor processing\manufacturing tool) plays the main role in the production Fab (Fabrication Unit) because, faster processing speed leads to faster growth and profit – looks critical to me.
With this in focus, Manufacturers of Equipment components are really pushing themselves to implement new techniques, upgrade and introduce new technology - Let’s consider a manufacturer JyounameitJ and let us consider him to be a servo drives provider and he is in the market for many years and has different streams of products. Even with his long term market presence and expertise, I bet, he will still have plans to improve hardware and software to provide better performance and reliability.
Are Equipment Control Software’s designed to adapt these improvisations?
Can the same communication module used to support new components?
Most Manufacturers and their software divisions never care about above questions until the component they use has support provided by its seller, but when the component is announced as obsolete by its seller and an issue happens with it, all hell breaks on communication model and control software interface of that component.
“We have to design our communication module to adapt any kind of Component Upgrades and improvisations; at least it should not expect you to rewrite everything”
Assume you have a single module to handle communication between Equipment Component and Control system which is working well so far,
Now say your company is planning to introduce a new component to replace a 10 year old one and the plan is to use both existing and new component based on customer request.
You will have to make a lot of design changes for the new component and the old component won’t adapt, and it is not entirely possible to hold both existing and new components in the same software.
“So it is better to split your component integration module into two, one for communication and one for managing it”
The manager module will be responsible for receiving the command from Equipment software and pass it to the respective communication module (Old and new).
The list of operation that needs to be done by the component could be listed as commands in Manager Module (For e.g. Pick, Place, Move, Grip, Ungrip, etc...) and When Equipment software wants to execute a command, it will invoke the Manager Module to route the command to respective Component (H/W) Communication module.
“[Command Design Pattern] would be more appropriate for Manager Module”
- By designing this way, it will be easy to support new components and will reduce development efforts and cost related to it.
- The Entire Communication Model need not be re-coded\modified whenever a new component is added to the equipment. Adding a lightweight Comm module for the new component will do the trick.
- This will also open up opportunities for Equipment manufacturers to grab and provide equipment for end customers with variant requirements in a short time.
- Adapting to new technologies and innovations will be easy and feasible with fewer efforts.
Hope you like this blog and will use the idea for your future designs.HCL's hardware engineering services provide tailored services across various verticals such as aerospace, automotive, hi-tech, medical electronics, consumer electronics.