I’ve recently been refreshing some internal training content for our Avanceon University and I wanted to share some items that we have found to be key in developing adult learning courses, whether the intended audience is our own staff or our customers. These eight design points help organize an effective training course and provide a framework for how to train and evaluate individuals.
1. Overall Training Objective – What is the training’s singular purpose? As an example, let’s talk about an overall training objective of providing controls engineers with basic System Platform troubleshooting tools.
2. Target Audience – Who is the training targeting? What is their background and experience level? For our example, this might be engineers who have not yet or just recently started with Wonderware.
3. Pre-requisites – What would attendees need to already know before attending this training? In my case, I would have wanted them to go through the prior training class, which is an Introduction into System Platform class.
4. Training Elements – What are the individual skills, tasks or activities that you want participants to learn? Make sure you break down the items as discretely as you can so that you have a more comprehensive offering and evaluation. There may be just a few or there may be a whole bunch. For this training example, I have a number of training elements. For the following questions, we can focus on the element of utilizing Object Viewer for detailed script execution information.
5. Objective Statements – Turn each training element into an objective statement. Objective statements are structured as follows: People (A), given (B), will do (C) to a level of (D) proficiency. For our example here, we might say Junior Wonderware Engineer, given an issue with a script, will utilize Object Viewer to ascertain the execution details of the script including, but not limited to, number of times executed, last date/time executed, average execution elapsed time, last execution elapsed time, number of times executed in error and did the last execution result in an error.
6. Resources – What item(s) does the attendee need in order to learn and demonstrate a given training element? These are typically things that need to be prepared in advance and given to the attendee during the training of that element. For my example training element, I would need a galaxy setup running a script that had a known error that I could point the engineer to troubleshoot.
7. Performance Indicators – How will you evaluate the attendee and know that they have mastered this specific element to the given proficiency? This might be demonstration, a written test or some other method. You should have an answer key, rubric or other scoring method to determine success on a given element. Here I would maybe create an answer key that would have what was wrong with the existing script and at least one acceptable correction to fix the issue.
8. References – What information needs to be provided for the attendee to accomplish a given element? This is especially important if you are creating self-paced training, but also if additional references might be helpful in developing a further understanding of an element beyond what is discussed by the instructor. For this example I might refer to specific sections in a training manual, user’s manual and/or deployment guide pertaining specifically to how to call up Object Viewer and what properties exist for scripts.
Have you found these to be important factors? What have you found is key to your training? Drop us a note and let us know. And don’t forget to tune in next time for another exciting adventure entitled either “Ar-‘Test’-ed Development” or “Classes with Curly”.
There comes a time in every man’s life when he must grow a beard. Within Avanceon I primarily work within the food and beverage business unit, but since Good Manufacturing Processes frown upon exposed body hair, a conflict with the aforementioned call to the wild presents itself.
So why beard? To some, facial hair is more than a style; it is a rite of passage. To others it is an act of self-expression. The act of not shaving also saves precious morning minutes. Above all else, though, it keeps my face warm during brutal winters. I’ve been growing an annual winter beard for the 3 years I’ve been at Avanceon (a previous employer disallowed any facial hair, blasphemers). I typically like to grow into a lightly manicured lumberjack beard, just enough insulation to protect from icy gusts of wind while not long enough to be mistaken for any cast member of Duck Dynasty. The perfect balance.
So why not beard? Good Manufacturing Practices must be executed while working in food and beverage facilities, which requires proper PPE, hair nets, and for those with facial hair to don a beard net. Beard nets, while protecting the quality of the product, can be irritating. Unlike the hard hat/hairnet/safety glasses, you never forget that you’re wearing a beard net. On more than one occasion I’ve sat down for lunch at a restaurant while wearing my safety glasses and hair net, simply forgetting that they are on. Such is not the case with the beard net. Other cons of the beard include food crumb accumulation, babies pulling on them, and the one month embarrassment period known as the “proto-beard”.
In the end, it’s all a matter of preference. Personally, I get more benefit from the warmth giving of the beard during winter months, so I tolerate the beard net. Once the weather warms up I reject the beard net and sport a naked face. How do you beard?
Do you remember the now classic scene in The Lion King where a group of hyenas are saying the name of the king, “Mufasa,” to each other and the mere mention makes them shudder? “Ooooh! Do it again!” In my experience, there is an automation product that has the same effect on engineers and customers alike. What product is that? Wonderware’s InBatch! No other software product has made my friends and colleagues shiver and shrink.
So why does InBatch instill “Mufasa” level dread? Oddly enough, the main reason InBatch is feared is the same reason it’s worthwhile. It’s powerful. InBatch is an incredibly flexible product that can do just about anything imaginable in automation and recipe management. But the only way to make it so powerful is to make it incredibly configurable. And that means that InBatch requires a pretty steep learning curve before that potency is accessible. People just don’t know how to use it. And when they try, their efforts often go poorly. It has taken me years and multiple projects to really get my arms around this software and figure out all the ins and outs and how-tos and what-to-dos. And now I feel like I am there. I am on board. The power is mine!
Over the past year and a half, I’ve been working on multiple projects with one of our partners who has had a long history with InBatch and has solid standards regarding how their installations operate. Their standards are highly integrated with System Platform, InTouch, and all the other Wonderware products. Their visualization approach prominently presents what is running and how efficiently without having to use the standard Environment Display tools. And the best of all, it works really well.
So for a year and a half, I’ve been living and breathing InBatch. I’ve been leveraging what we’ve done in the past. I’ve been learning from what our partner is doing. I’ve been adapting what I know for new project challenges. The thought of the next InBatch project no longer fills me with terror. I’m looking forward to the next opportunity to use this powerful software.
So do you fear InBatch? Tell us about your experience!
Throughout my years working in systems integration – technician, engineering, management and owner since 1976, I have experienced the many downfalls of downtime and the snowball effect it causes for everybody involved. I have worked extensively in the Life Sciences industry providing validated designs and installations, unscheduled downtime no matter what industry can be frustrating and expensive.
Unscheduled is the key here…as most production systems experience some form of downtime (both scheduled and unscheduled). The big killer in the unscheduled downtime is the reaction time to notice the issue, diagnose the problem and solution and then to mobilize to correct the problem. In scheduled downtime the solution is usually defined and the mobilization is planned before the system goes down, thus the unproductive time is minimized (= less lost revenue).
Whether a downtime tracking program or a manual means of listing the typical downtimes is used, the goal is the same: predict the types and occurrences of unproductive machine time, allowing for the preparation of shorter and less chaotic machine interruptions. This all equates to higher productivity from the same resources and a more consistent quality product.
Here are some other ways to eliminate unscheduled downtime, link .
By: Duane Grob
NERC (North American Electric Reliability Corporation) held its second grid security exercise, or GridEx, over a two day span. During this exercise, nearly 10,000 electrical engineers, cybersecurity specialists, utility executives and F.B.I. agents wrestled with an unseen, virtual “enemy” trying to disrupt the electrical infrastructure in the U.S. It included simulated computer viruses, line and equipment damage and even first-responder deaths in an effort to understand and evaluate participants abilities to understand, communicate and neutralize a multitude of simultaneous threats.
This type of exercise is important for those people and organizations involved in securing our cyber infrastructure to help gain a real-world(ish) and real-time analysis of the structure and procedures in place guarding these assets. As shown in a recent Control Engineering feature article, the ability of cyber intruders to gain access to networked control systems might be easier than previously anticipated. Their cyber security experiment revealed that the lesser skilled and inexperienced hackers did not realize that this was a “honey net” or fake asset used to lure them, were able to find, access and manipulate these fake municipal water utility network control systems.
As a result of technological and geo-political changes, some industries have made changes in the form of regulations to put specific requirements in place around critical infrastructure security. Many of these industries, such as power generation, nuclear, chemical and water, are maybe obvious institutions where such focus on security is warranted. Regardless of your opinion of the likelihood of cyber and infrastructure attacks, most will agree those groups represent the likeliest of targets. With the goal of such attacks being to strike fear, disrupt everyday life and cause physical and economic damage. Especially when weighing all of those potential repercussions to the population at large, one can understand the reasoning behind these regulations. But where does that leave other industries that have similar infrastructure, technologies, and presumably, security gaps?
What are the security risks and potential consequences associated with a pudding or ibuprofen manufacturing line? Unless the process consists of superheating a vessel or something similar, the chances are probably very low that any significant physical damage or destruction might result. That leaves the most likely consequences revolving around a bad batch or amount of product based on changes that were made to things like set points and other quality-influencing parameters. The chances that such bad quality would actually leave the plant and make it’s way to the consumer is fairly low with the quality procedures most companies implement. Therefore it’s left mostly to a corporate sabotage-type motivator to cause them to create and scrap a lot of waste product (or unnecessarily consume raw materials, etc.). While the loss of a batch or materials might have some real cost significance, because that threat is solely based on strictly wanting to financially impact their target, the likelihood that someone would be skilled and motivated enough to pull off such an act, is perhaps relatively quite low.
So do those industries then not concern themselves with cyber security? Is the low potential for motivation and the ‘havok’ that can be caused reason to say that the costs of securing systems outweighs the risk they are protecting against? Or does the fact that people out there can access these systems and ‘do bad things’, justify the costs associated with keeping these assets secure?
By: Brian Fenn