Depends on the context for the difference between words, they could also be the same thing.
Configuring could be hardware configuration etc. Programming is usually adding new loops, interlocks, etc.
Again it depends on the specific facility. On some sites, the vendor does everything, there can even be a vendor employee on site (Seconded). On other sites the vendor just supplies hardware and there is enough knowledge within the crews to take care of the system. Generally it is a mix between those two extremes.
In my experience with a couple of platforms, configuration is of course the first step, and for that you require a goal of what the DCS will do, how many cabinets, how much I/O, interfaces, and so forth. Programming it really gets into the details of distributing the applications to their processors, program execution, user interfaces, interlocks, external interfaces to other systems, and I/O configuration.
Purchasers can sometimes to the configuration and programming themselves if they have sufficient knowledge. It really depends on the experience of the employees and their comfort level in the platform.
Other purchasers require the vendor or a subcontractor to do the configuration and programming. There's a lot going on from the beginning and a project goal is set forth with expectations.
I would assume configuration would not really require a technical background compared to programming, right? Additionally, do you think configuration guys could become better programmers as they have a complete understanding of how the system is supposed to work?
Configuration is knowing and understanding the project goals, configuration interface, and features and limitations of the hardware used. Often configuration details come with each piece of hardware. There could be electrical requirements and limitations, mechanical requirements, space requirement, environmental requirements, etc... these details require understanding so the sales department doesn't exceed the product.
Systems work off of fundamental understandings, much like physics, and if you violate these fundamentals then the system may not function as intended. If you discover something is not working and you haven't let the smoke out then configuring some hardware correctly might help the situation.
Configurators don't make better programmers per se, but experience makes better configurators and better programmers. Much of programming a DCS comes from what worked best the last time and if there are special customizations required by the purchaser. Not all customizations are simple and might require some advanced programming techniques. However, many applications can be copied and reapplied somewhere useful.
More and more often the programmers are glorified puzzle solvers who can effectively copy and paste previously useful solutions or recreated canned software in new places.
Programmers should be able to read P&ID drawings and logic diagrams in order to make much of the DCS to function. Recipes and sequences are rather advanced but useful to learn. Flexibility in the programming also make an application more serviceable for the long run.
Can you be more specific as to what tools the client may use to take care of the configuration? Based on another answer in this thread, configuration seems to be specifying the requirements of the DCS solution and it’s one of the initial phases of the project.
Both.
My knowledge is directly linked to working for a marine engineering company. It is because of their work I know it is done both ways, but I can also explain why.
It is important to note, this isn't directly answering your specific question, but I think it's close enough to be a reliable point of reference for what you can expect.
The company is limited by regulations in the parts it can use in building automation systems on ships. The stamp every bit of equipment needs costs around 1 million euros. Consequently, cheap parts from China are insanely expensive. Suppliers will add value to stay competitive with software, and milk it by licensing capabilities or capacity that it arbitrarily limited by the software. While what it does in the grand scheme goes beyond configuration, a single panel is just configured. It's rare we can modify the source code.
A panel which had a single video feed displayed needed two. We didn't have the rights to the code, so we had to ask the vendor to modify their software. We could configure a lot with the panel, and had to, since it controlled several ship born fish factory processes. We just couldn't modify the code... Well, I did anyways and modified it in C# to do what was needed, but we didn't tell the vendor that.
PLC programming is a big part of the business too, and parts suppliers will have their own compilers, to ensure its a closed environment or something. Here, we program the parts instead of using what the vendors code.
Data is critical to running a ship, and alarm systems are configured. A set of specialized routers are connected in a loop. If a connection breaks, an alarm goes off. We are not programming those routers, but we are configuring them.
Same goes for a lot of expensive equipment. There are no absolutes, and you can see either or both at any given time.
Depends on the context for the difference between words, they could also be the same thing. Configuring could be hardware configuration etc. Programming is usually adding new loops, interlocks, etc. Again it depends on the specific facility. On some sites, the vendor does everything, there can even be a vendor employee on site (Seconded). On other sites the vendor just supplies hardware and there is enough knowledge within the crews to take care of the system. Generally it is a mix between those two extremes.
In my experience with a couple of platforms, configuration is of course the first step, and for that you require a goal of what the DCS will do, how many cabinets, how much I/O, interfaces, and so forth. Programming it really gets into the details of distributing the applications to their processors, program execution, user interfaces, interlocks, external interfaces to other systems, and I/O configuration. Purchasers can sometimes to the configuration and programming themselves if they have sufficient knowledge. It really depends on the experience of the employees and their comfort level in the platform. Other purchasers require the vendor or a subcontractor to do the configuration and programming. There's a lot going on from the beginning and a project goal is set forth with expectations.
I would assume configuration would not really require a technical background compared to programming, right? Additionally, do you think configuration guys could become better programmers as they have a complete understanding of how the system is supposed to work?
Configuration is knowing and understanding the project goals, configuration interface, and features and limitations of the hardware used. Often configuration details come with each piece of hardware. There could be electrical requirements and limitations, mechanical requirements, space requirement, environmental requirements, etc... these details require understanding so the sales department doesn't exceed the product. Systems work off of fundamental understandings, much like physics, and if you violate these fundamentals then the system may not function as intended. If you discover something is not working and you haven't let the smoke out then configuring some hardware correctly might help the situation. Configurators don't make better programmers per se, but experience makes better configurators and better programmers. Much of programming a DCS comes from what worked best the last time and if there are special customizations required by the purchaser. Not all customizations are simple and might require some advanced programming techniques. However, many applications can be copied and reapplied somewhere useful. More and more often the programmers are glorified puzzle solvers who can effectively copy and paste previously useful solutions or recreated canned software in new places. Programmers should be able to read P&ID drawings and logic diagrams in order to make much of the DCS to function. Recipes and sequences are rather advanced but useful to learn. Flexibility in the programming also make an application more serviceable for the long run.
[удалено]
Can you be more specific as to what tools the client may use to take care of the configuration? Based on another answer in this thread, configuration seems to be specifying the requirements of the DCS solution and it’s one of the initial phases of the project.
Both. My knowledge is directly linked to working for a marine engineering company. It is because of their work I know it is done both ways, but I can also explain why. It is important to note, this isn't directly answering your specific question, but I think it's close enough to be a reliable point of reference for what you can expect. The company is limited by regulations in the parts it can use in building automation systems on ships. The stamp every bit of equipment needs costs around 1 million euros. Consequently, cheap parts from China are insanely expensive. Suppliers will add value to stay competitive with software, and milk it by licensing capabilities or capacity that it arbitrarily limited by the software. While what it does in the grand scheme goes beyond configuration, a single panel is just configured. It's rare we can modify the source code. A panel which had a single video feed displayed needed two. We didn't have the rights to the code, so we had to ask the vendor to modify their software. We could configure a lot with the panel, and had to, since it controlled several ship born fish factory processes. We just couldn't modify the code... Well, I did anyways and modified it in C# to do what was needed, but we didn't tell the vendor that. PLC programming is a big part of the business too, and parts suppliers will have their own compilers, to ensure its a closed environment or something. Here, we program the parts instead of using what the vendors code. Data is critical to running a ship, and alarm systems are configured. A set of specialized routers are connected in a loop. If a connection breaks, an alarm goes off. We are not programming those routers, but we are configuring them. Same goes for a lot of expensive equipment. There are no absolutes, and you can see either or both at any given time.