How To Understand RFQ In Industrial Automation

26th  May, 2024.

In this post, we will see how to understand RFQ in industrial automation.

RFQ (request for quotation) is a document which is used in each and every field by customers to give technical enquiries to the vendors. It helps the vendors understand the requirements of a customer and quote them accordingly. In industrial automation, RFQ plays a very important role for a client, because the system is complex and failing to explain it properly will eventually lead to a wrong or bad product. On the other hand, it is equally important for a vendor to understand the document properly so that they tailor the design and give their offer accordingly. In this post, we will see how to understand an RFQ given by a customer in industrial automation and respond to it accordingly.

What is the purpose of an RFQ?

RFQ stands for request for quotation. When a customer wants a system, he needs to first explain his technical requirements according to other information like the last date for accepting an offer, estimated dates for the final product or service delivery, and other general terms and conditions. For this, RFQ plays a very important role as it is a document designed for this specific purpose. The vendors will be streamlined to a proper path in deciding the offer by this document. So, when a customer writes this document, he must note that first of all, the technical requirements must be specified properly. RFQ for this reason plays a note in project management, without which the project cannot be kickstarted properly. Because if the vendor is not able to understand what you need, then how will they be able to give you a proper offer? One thing to note is that it is not a firm offer, but will give a brief idea to the vendor what the customer requires. 

RFQ for an industrial automation project:

Industrial automation is a very complex system and requires proper understanding of the project. This is because so many things like PLC, SCADA, control panel, networking etc. are involved. When a customer wants to install an automation project in his plant, he must explain first of all what he needs. As our post is related to understanding an RFQ and not writing it, we will directly jump into the topic. Let us consider that an RFQ has been prepared by the customer and sent to you as a vendor. Now, it is necessary how you interpret the document and understand what is required technically. One must not forget the budget and try to keep it under control for your order to be technically approved; so for this, the design must be made accordingly. We will not consider the electrical panel part as it is a completely vast topic; only the automation part will be covered. Let us now see the general points which are covered in RFQ for an industrial automation project.

1. IO counts:

The very first thing to understand is how many input and output counts the customer requires. As we know, there are four types of IO’s - digital inputs, digital outputs, analog inputs and analog outputs. The customer will specify how much quantity each of these four will be required. Now, you will have to decide what PLC you will need to offer. There are so many PLC manufacturers in the market that a new service provider will get confused. If the provider is an automation expert, then no issues; as he will be familiar with the PLC’s which will have this much of counts. But if the provider is new, then the simplest method to refine is just go to Google and type - PLC with n digital inputs, n digital outputs, n analog inputs and n analog outputs. You will be nearby given the matching results where you can then choose the required one. Analog input and output type must be specified correctly by the customer, so that you can choose the corresponding analog module. Also, the customer will write spare IO counts, so when choosing the PLC or module, consider that too in your total configuration.

2. IO system architecture:

This is one really important factor. There are four types of IO system architecture - local (only PLC), local with PLC and HMI in built, remote and distributed. Refer to the below image. A local PLC will have in-built IO’s and you can expand the IO’s by connecting expansion modules with the main CPU. A local PLC-HMI controller has in-built IO’s as well as HMI display too embedded on it. Remote architecture is the one where only the main CPU will be present without IO’s, and the IO’s will be connected to it through IO adapters and modules on a common communication protocol (they do not have provision for any logic writing; it will be done in the main CPU). Distributed architecture is the same as remote one; the difference being that small-scale CPU’s will also be present with IO adapters (used for large scale applications where distributed logic helps in efficient performance and this small logic will directly be shared with larger logic written in the main CPU).

So, when you are sure of the first point, you need to decide which architecture you will propose to the client according to their estimated budget. The first two are cheaper options, but provide less flexibility and are suited for smaller applications and a limited area of field instrument location. For systems where the application is large and IO’s are present in far locations, the third and fourth option are suitable. When you want to distribute logic written for such locations and bring them on a common platform with less memory consumption, the fourth architecture is used.

3. Communication protocol:

Mostly, the client leaves this part on us to provide them the best. They will say that they have some n number of devices which need to be integrated in the main CPU for data sharing. Accordingly, the most used protocols of Modbus, Ethernet, CAN open or other must be considered depending on what the PLC is providing. One main thing to consider is how long the cables will be laid between devices. Choose the one which performs the best for longer distances (specially Ethernet is used). Also, they will specify that they need a spare communication port for integration with some higher automation level or at least for programming. Ethernet is not an issue as it can work on network switches and can be expanded to many devices through the switch. But other protocols require consideration. 

4. HMI configuration:

You need to understand the scalability of the project the customer is designing, and from that, you can choose the HMI depending on factors like screen limitation, tag limitation, alarm limitation, trend (graph) limitation, and data logging facility. HMI communication ports must also be taken into consideration for further expansion if required. Some customers demand printing, so the HMI which has a printing facility needs to be chosen. Also, you must consider how many slave devices can be integrated in a single HMI, so that the customer demand can be met.

5. SCADA PC configuration:

SCADA is a higher level than HMI and runs on a computer. So, apart from standard HMI factors we looked, PC specifications must be considered like CPU, RAM, processor speed, display size, USB connectivity, network ports, antivirus (if required or not with license), and MS Office (if required or not with license). Also, as SCADA works in big systems, client requirements like redundancy, number of clients, OPC connectivity, database type support, cybersecurity, supported communication protocols, and 21 CFR compliance must be taken into consideration.

For a detailed study, I have given the below links which will help you understand more easily.

IO counts - https://automizeindustry.blogspot.com/2021/01/troubleshooting-plc-digital-ios.html

        https://automizeindustry.blogspot.com/2021/01/troubleshooting-plc-analog-ios.html

IO system architecture - 

https://automizeindustry.blogspot.com/2021/01/difference-between-local-io-remote-io-and-distributed-io.html

Choose a PLC - 

https://instrumentationtools.com/how-to-choose-a-plc-for-new-project-criteria-for-selection-of-plc/

Choose HMI - 

https://instrumentationtools.com/choose-hmi/

Choose SCADA - 

https://instrumentationtools.com/how-to-select-a-scada-for-new-project/

I have covered a general theory related to RFQ in industrial automation. I have also not attempted to cover all the concepts, as it can vary from systems to systems. Once you are familiar with this engineering, you can easily tackle all types of problems in it.

Thank you for reading the post. I hope you liked it and will find a new way in this type of technology.