The entire ep5BAS project is built on the efforts of our volunteers. Your contributions are appreciated by not only ep5 but everyone who will use the ep5BAS software to automate something useful. Add to this the educational value of the ep5BAS C# code, and you have something to be proud of.
How does volunteering work on the ep5BAS project? It's as simple as it is informal: let us know what your specific area of skill and interest is, and we will discuss with you the work needing doing. Work on it at your convenience, and we will provide the test suite on which your code will be validated.
NOTE: the skills we’ve identified below in red are of particular interest.
PLEASE TAKE NOTE: expertise and experience in C# are mandatory for those volunteering to write program code.
The project will succeed on the strength of how well coded it is. It will not be enough that it works. The C# code must exhibit the qualities of workmanship and adherence to best practices expected of the finest teachers. Unlike the ordinary program, which appears in front of the user in executable form, ep5BAS will be source code. It will all show.
An important part of the ep5BAS project is that it's also educational and thus must appeal to beginners and those with intermediate skills in software development. This means an abundance of useful comments and none (or fewer!) of the coding tricks used to minimize SLOCs, conserve memory, and impress the other programmers.
Unlike a conventional program, which is generally the same for all of its users, automation programming by definition must be adapted to the precise circumstances of each application. For this reason, our initial undertaking will be created in the form of template modules and programs intended to minimize the amount of work which each instance of the software will require. This will take the form of at least one full example of each type of control, leaving the user of ep5BAS to add and subtract capability rather than invent it on her own.
If you're as old as we are, you remember the days when a programmer could start a job by sitting down at the card-punch machine and whipping out as many lines of code as he could, as quickly as he could. Those days are well and truly gone, at least at ep5BAS. We agree with Edsger Dijkstra about planning first and coding second. In the event you're wondering, he said “Weersta de drang om code te schrijven.” (Well, he was Dutch.)
Careful planning notwithstanding, we welcome original ideas about how to do things. ep5BAS, by its nature, has room for differing ways of accomplishing a given task. ep5BAS not only allows but encourages as much variety and innovative programming as proves feasible in practice, so we're attentive to ideas, even the wild & crazy ones.
The application of versioning to open-source projects is well established, and we're open to as much or as little of it as may be optimal and in whatever form works best. You're the expert...
Documentation has always been a point of particular concern to us. If it doesn't provide useful and usable assistance to the beginner, then why bother with it? It should not simply repeat what is obvious, and it should make as few assumptions as feasible. It must reflect the code as it exists now, not three versions back.
The project docs will embody the same attention to thoroughness that will characterize the code itself. Software God hath spoken.
It is in the nature of industrial, process, and building automation to interoperate with devices running software alien to the .NET universe. Moreover, there's a big difference between collecting and shipping data for logging and subsequent analysis and moving live control data back and forth with real-time determinism. At this stage in the project, we anticipate working with a broad and eclectic variety of hardware, necessitating interjecting unmanaged code between the C# program and foreign device drivers.
MQTT and OPC-UA may prove significant in ep5BAS programming, and we want to keep them in the curriculum.
Unless your imagination is better than ours, you'll agree that there probably is no such critter as a building automation system which does not interact with any external hardware. Because ep5BAS programs will rely closely and critically on I/O systems, we want to have access to demonstrable ability in the integration of such hardware with our code.
This means a specialist in the fine art of assembling heterogeneous components and persuading them to play well together. A familiarity with at least a few of the major suppliers of this kind of hardware will be useful.
Note that we are not affiliated in any way with individual manufacturers and plan to keep a fully open mind. Our policy is vendor neutrality. That having been said, we've been around long enough to understand that there is and can be no substitute for reliability in hardware and hardware supplier.
If you know of sources of industrial-quality I/O hardware which can be used in the processes automated by ep5BAS, please consider helping us look into them. The criteria for inclusion center principally on the ease with which C# code can read from and write to the proprietary systems and subsystems. We are even willing to work with manufacturers seeking to expand the applicability of their product range by opening their hardware to user-created .NET software.
If you know exactly what that means – without looking it up! – then we'd really like to talk with you.
The elephant in the room is the vast installed base of existing systems and new components, such as high-end process controllers, utilizing Modbus and other protocols for communication and control. ep5BAS will positively require easy-to-implement code for living and working comfortably with these devices.
Ideally, this means neatly packaged off-the-shelf code which can routinely and freely be inserted into anyone's C# program to enable it to utilize the fieldbus features, as needed. This, in turn, means someone with close and comfortable working familiarity with coding close to the metal.
Ethernet shows abundant evidence of dominating the industrial workplace almost as much as it has in the office space. Nonetheless, the older technology certainly will not fold up its tent and steal away into the night. Outside of the consumer market, mature technology, even that which has become universally regarded as obsolescent, tends to linger. As a consequence, ep5BAS definitely has a place for those experienced in any of the established fieldbus technologies. Talk to us; we're listening.
What open-source project ignores GitHub? Not us! Familiarity with the details of GitHubbing will make you an instant VIP at ep5BAS.
As the objective is usability on all three major platforms, and since installing a program is not as simple as it was back in the Bronze Age, you will earn your accolades by providing ep5BAS with a bullet-proof toolset for placing the executables where they need to be in such a way that they work.
Our intent will be to make ep5BAS programs as straightforward to install as the technology allows. Uninstallation (horrors!) must be equally simple and easy, with no file debris left behind on the user's computer.
In process control, in all its many forms, the computer running the control application will not always be a conventional desktop. In addition to industrially hardened desktop equivalents, there may also be more unconventional hardware platforms, such as the increasingly capable pocket-sized single-board devices, such as the Latte Panda. We see an abundance of opportunity in such devices hosting ep5BAS programs.
We plan to make concurrency part of ep5BAS, but only where, when, and as it makes a genuinely valuable contribution to the software's capability. Thus, it will almost certainly not be used in main event loops but would be utilized to facilitate running multiple control schemes simultaneously. You will need to know mutexes, semaphores, threads versus processes, waiting, async operations, parallel programming, thread-safety, and all the other gory details of C# concurrent programming really, really well.
The 8255 PPI Mode 0 TTL DIO control model may be ancient, but it's still exceedingly useful for digital control. It enables control systems to turn things on and off and detect and report back on machine state with minimal delay and latency. To do this, it encodes the state of eight I/O points in one byte. Therefore, the ep5BAS programmer needs to turn these bits on and off individually. Equally, she will need to read machine state byte-by-byte and immediately extract the individual channel states.
Thus, the image above represents in the byte, “155”, inputs or outputs OFF (8255 TTL DIO reverse logic) in positions 0, 1, 3, 4, and 7.
We need to make this as fast and easy as possible, using simple bit-manipulation functions, callable from the top of the main event loop (and anywhere else).
But, wait! There's more! Some hardware generates interrupts to signal the controller that a change has occurred, rather than wait for polling. This, too, must figure prominently in the ep5BAS programmer's toolbox.
Expertise in writing queries and stored procedures will count a great deal.
Databases will certainly play a major role in most ep5BAS applications, whether for logging of system events, alarms, and upsets or for storing control-specific data. An example of this would be sunrise and sunset times for each day of the year, loaded by the program into a LUT for use in, for example, lighting control.
Choice of the optimal database will involve ease of use by the programmer as much as it will features and raw power. It may safely be assumed that ep5BAS will not be used to create a long-distance telephone billing system dealing with half a billion records a month. (If it is, we want a cut of the revenue.)
Of significance in this will be the availability and programmer- and user-friendliness of the maintenance toolset. A database maintainable only by command-line tools will not suffice. A free version for personal use only won't do. It must be free for all uses.
This feature will turn on the availability of qualified volunteers willing to investigate the extent to which NoSQL databases might prove useful here. To be taken seriously in the ep5BAS context, this technology would need to demonstrate substantive advantages over conventional SQL.
In simplest form, for those control programs which repeat a process until stopped, recipes are the thing. We will need to provide templates for editing these recipes and doing the customary database operations via a graphical UI.
Initially, ep5BAS will consist entirely of console code. At some point, however, operator interface displays will be apposite, and this means venturing into the world of graphics. Specifically, this will involve creating mimic panel templates for screen displays facilitating operator interaction with control systems. Given current practice, this means fully exploiting touchscreen technology.
Like the paperless office, the paperless factory remains a long way off. ep5BAS will include as much utilization of the C# printing capability as we can squeeze into it. Our emphasis will center on using graphics primitives to create impressive business forms, such as work orders and invoices with different images for various items. We've done this before, and it impresses the customers.
This won't be an integral part of the C# coding, but it's still a valuable resource for us. If you look carefully at the main ep5 website and then at this subdomain website, you'll see something like a twenty year difference between them in æsthetic style. That's because the main site was done by experienced web design people who know what they're doing and . . .
. . . need we say more?
The importance of in-program networking derives from our objective of making remote I/O fully as capable and convenient as local I/O. Further, we have signed on to the Ethernet consensus and expect to restrict our connectivity, for the most part, to Ethernet.
In general, we will not use Ethernet to duplicate services provided by the underlying operating system, such as moving files around, nor for those provided by existing software, such as backups. Rather, our interest in Ethernet will center on facilitation of closely-coupled remote operation of automation. This will range from sending occasional updates to remote computers running stand-alone programs to active real-time use of remote computers as I/O processors.
That having been said, existing hardware will often be found to rely upon RS-485 serial connections over twisted pair, and we'll need to accommodate these comfortably, efficiently, and, above all, reliably. This goes hand-in-glove with Modbus RTU.
Serial communication features in ep5BAS will be limited to hardware-specific requirements, such as those involving devices with no other form of comms built in.
This entails not only designing and setting up a forum for free discussion of ep5BAS but also moderating it. We're for free speech, but the crazies will need to go elsewhere.
It may not be listed on Monster.com as an IT skill in great demand, but we need it. Whether to request technical assistance or to talk a company into supporting us in a more material fashion, we will benefit enormously from your ability to negotiate diplomatically and persuasively.
What is a “real-world expert”? She is someone who, like your friendly neighborhood physicist, knows the difference between energy and power, and also knows the practical aspects of why they are not the same thing at all and must be addressed appropriately to those differences. She understands how to interpret historical and real-time information about both of them and, from that, develop a strategy for minimizing day-to-day waste of the former by precise programmatic control of the latter.
To this end, our second real-world application of ep5BAS will be a rudimentary energy conservation module. Making this happen will require a working knowledge of the hardware used to measure voltage, current, power factor, demand, and every other physical aspect of energy management. Also needed, a good familiarity with the techniques of the trade, such as load-shedding and demand scheduling.
We will have need for real-world expertise in other areas, as well. This includes HVACR, a field which we see as having considerable potential for automation, especially at the lower end of the scale. Another is private water supply systems in rural settings.
It's money which makes things happen. At ep5BAS, the industrial hardware on which the code is tested carries non-trivial prices, and outside funding will be vital to sustain the lab in which we simulate real-world application of ep5BAS features.
Need we say anything about the quality of documentation of software these days?
Ours will be the exception. No one else better understands what the code does than the programmer who writes it, so documentation begins here. The coding job will not be considered completed ’til this is done. But, it does not end here. Good programmers are rarely good writers, so we will then run the documentation through our post-processor, who will refine the substantive wisdom written by the coder into a textual resource that will provide genuine and abundant value to the ep5BAS user.
One of our core principles is never requiring the user of ep5BAS source code to flounder about trying to find an explanation of what is happening in front of her. The documentation is not a trifling add-on tacked onto the product before it ships and done by the lowest-paid person on the team. It's a fundamental part of ep5BAS and gets the respect, time, and effort that it warrants.