I am a student who is consulting with a nearby company to develop a demo for their controller that is an alarm system for grain elevators. They currently have a demo that takes up a large suitcase and are trying to shrink the size as much as possible. I need to populate a board that will be able to simulate various sensors that are controlled through an hmi. Also, they want the ability to plug in their actual sensors and override one of the simulated sensors. I don't need a complete breakdown of how to do it or exact chips to use but I would really appreciate suggestions on how to accomplish some of these challenges. Below is my breakdown of the requirements.

Power:

• My controller is powered by 120v and has a 24v power supply. Or they can be powered by 24v directly. We use computer style power ports with fuse
• Option to power units via USB battery bank or a power tool battery. (this is a want not a need)

Board Outputs:

• 5 digital outputs simulating what is basically a limit switch. (alignment/level)
• 4 24v. analog outputs can simulate a ¾ turn pot. I am simulating a NTC thermistor. Attached is the resistance chart. (temp). this needs to range from -40f to 300 F.
• 1 24v PNP pulsed output going from 0 to 1000. (speed)

Board Inputs:

• External sensors:

A minimum of 6 wire input to hook up external sensors. (pass thru connector) External sensors are used to replace simulated outputs. External sensors will replace the following 2 digital outputs, 1 analog output (NTC),1 24v PNP pulsed output. and a auto/manual way to switch to the sensors.

4 total sensors with one return wire each, 2 wire for power gives me the 6, thinking we have a 7th wire that would trigger the simulator to switch to the external sensors automatically. Currently we use switches to flip from simulator to actual sensor. was thinking using mosfet for switching?

HMI:

• Currently use switches but like to go to touch screen. HMI would need to control the items listed in the output section.
• Should have a manual override option for external sensors on and off on a setting screen.
• To adjust analog temp would like to have 4 settings change by tapping icon. (Off, 1,2,3). These temp values should be able to be programmed on a setting screen. each one should be able to be adjusted on that setting screen.
• Digital outputs should be on or off via a touch of the icon. Will be alignment icons and one plug sensor icon.

 

Welcome to AAC.

Is this is a project for academic credit?

 

First, some general advice. (At the end of this very long screed there are some notes on "practical" things, but I value the content of the screed far more, having paid for it with many mistakes and hard lessons)

Your requirements list and cogent write up give the impression that you have approached this thoughtfully and systematically. This is very good and a great head start. Even professional designers can easily fall short in this area and a desire to "start soldering" (or writing code, or drilling, or whatever they mainly do) can easily cut short the design and thinking phase with dire consequences later as assumptions and ignorance get baked into the design.

Remember that any choice you make early on has the potential (and probability) of becoming a fixed point on which the entire project will be forced to pivot. Avoiding such fixed points until you have a high confidence level, and limiting their number, is critical to a truly successful 1.0 version of your device and a chance that 1.1 will actually be able to correct the unforeseen (and it will be required!)

You can avoid these this pitfall in a few ways. First, make drawings and models! Schematics, physical wiring diagrams, 3D models, PCB layouts, and any other artifact on paper or in easy-to-manipulate materials that helps visualize the relationships among parts will be your first defense against making "stupid" mistakes that cause face palming later. This is an incredibly valuable tool that you should develop your relationship with so you can do it the right amount for your personal needs.

Initially erring on the side of excess (while attending to the production schedule) is a good idea. The point of this is to save time later and reduce the requirement to jam things in that really don't fit—either logically or physically.

Plan for and make non-production prototype(s). Make sure your client is aware that you will have to make a prototype prototypes to test the design. Creating prototypes of subsystems allows you to test functional parts of your design in isolation, connecting these together can test the whole thing as you create working pieces.

You should be aware of a special risk concerning the client. Today, we can make a prototype using cheap and cheerful PCB manufacturing, breakout boards and modules for key parts, and 3D printing, laser cutting, and other rapid manufacturing techniques that can, to the client, appear to be a finished product but actually isn't.

They may get the impression that you are "nearly done" when you are actually only halfway to finished. This can lead to confusion and dissatisfaction. As a consultant you will have to manage the expectations of the client. Providing a roadmap on the design and build project with milestones, and meeting ahead of time to communicate it can make a huge difference. It is also critical to provide regular updates on your progress, with details.

They may not understand the content of these updates but it will demonstrate progress and can be tied back to the roadmap. This may seem to be extra work and unnecessary but I can tell you form long experience it is very important if you want to be able to do work you can not be embarrassed by later, and that actually works (according to the definition of "works" agreed upon initially).

One critical piece of success here is to design in a modular fashion. This starts before anything is actually fixed except for the problem. The solution to the problem is your goal, once your solution becomes the problem, you are lost. This is part of the pivot problem described above. So how do avoid this?

First is naming. As you design, hard- or software, name things for what they do. That is, think for a long time about the function of some subsystem, variable, or control and give it a name that as deeply describes its function in the context of the system as possible. Make sure the names of any parts that are exposed use the language used by your client in talking about them, this is very important both in how "intuitive" the interface is, and how easily you will be able to satisfy the requirements.

For other things, keep in mind that a name is like a handle by which you can grab something. You want it to be easy to figure out which handle to grab and to be sure it gives a good grip on what you intend to grab with it—and not on some assortment of things. The name should explain to you what the things is going to do, even to the point of surprising you by showing you unexpected aspects of the things function as you learn more about how things are interacting. Getting the names right is a huge part of being ready to build your system.

The modularity comes when you see each part of the system as a completely replaceable black box. Modules should be initially specified by saying what they accept (signals, variables, whatever is relevant) and what they provide in the same terms. This applies to hardware subsystems and software functions equally. Whatever you name them, never fall to the error of using something internal to them in a roundabout way for convenience. Permit them to be encapsulated, that is, to be accessible only through the defined I/O interface(s).

In this way you will be able to rip out a given subsystem or function and replace it without finding it embedded with a web of special cases that make this impossible. In the case of hardware, this modularity can be literal, with connectors in and out (and this is sometimes very useful, such as "I/O modules" which, in your case might allow for expansion if needed) or, it can just be logical and fixed on the PCB, useful for revisions but not configurable per se.

These subsystems also allow clear(er) thinking about the overall system. You will be able to build and test subsystems in isolation, connect them for testing and verification, etc. Again, keeping the functions of the modules normalized, that is, all ensuring that all of the things inside the module and behind its interface are tightly coupled to the name of it, is critical.

Beware of feature creep. This is a pervasive problem and can be made much worse when there is a poor balance of client and consultant "power", as in your case where you are a student and there can very well be people in the organization that "know better". The best defense for you is to engage with anyone with strong opinions that might weigh in as a group in a meeting or few meetings where the roadmap is discussed and finalized.

If they come later and say "we need to add [feature X]", the response is to pull out the roadmap and say, "OK, what will we discard to fit this in?" Usually, this drops the new request, if not, you will at least be sure they aren't adding to the specification but not rot resources. And "simple requests" can very, very easily become complicated time sinks.

Any request made after the roadmap is agreed should be treated as a high overhead item. Note that if you think it really is a simple request, refuse it based on this cautious management of resources, then give a quick attempt at adding it without saying you will. If it "just works", go back and say "I was thinking about your request and I found a way to integrate it as I was working, so we can add it".

Also note, if you got your naming right you will find that a lot of these requests require almost nothing to be added because they are an inherent part of the functionality of your subsystems. This is very satisfying. That's why the front loaded work characterizing the problem (which is what your subsystems and their names is all about) is a real force multiplier.

There is a lot more, but if you do these things to the extent you have the time and understanding to do you will find them to be extremely empowering when it comes to producing a 1.0 version that is actually quite good and doesn't have to torn up to make a 2.0 version.

OK, initial practical observations.

If the limit switches are mechanical ones, I would use relays so they are mechanical switches. If they expect something else, use that. You can potentially make them selectable between relays and the transistors you are using to operate the relays using jumpers or DIP switches but whatever the sensors actually use to do the switching, do that.

For your NTC simulation, a digiPOT (Digital Potentiometer) seems close to ideal. This Maxim part can be sourced as 200KΩ and has 256 taps for the internal resistor matrix. It has I²C interface making control easy.

My first impression concerning the external sensors is that the least risky way to switch them would be relays (reed relays might be good) rather than solid state components. This is because a relay will basically provide a wire while a sold state component—MOSFET or BJT—provides a connection to a junction and you will have no idea what might get hooked to this in the future.

This follows the basic "KISS" principle, in this case to future-proof the device from those who will connect things to it long after you have moved on. To that end, OVP/OCP is also a good idea. Fuses, TVS diodes, Zeners, etc.on the inputs could protect the device from a nasty surprise when someone does something... innovative.

Also be sure to provide good noise suppression on any physical I/O using ferrites or other ways to keep from having something glitch the MCU every time it switches.