I have been very fortunate in my career, and that really means very lucky. Upon graduating from the University of North Carolina at Charlotte, I had two job offers after sending my resume to more than 100 companies. That is not a very good yield, but it would be good enough. I selected the smaller company, but I selected that company because they created new things. The company I started at developed embedded industrial control systems. It also turns out the people with which I would be fortunate enough to work, were very friendly, and as I would say, were a hoot to be around. Some of my other blog posts describes shenanigans. To this day we still have secret words, that mean something to us but nothing to anybody else (R4).
What drives me
My interest or objective has never been one thing when it comes to product development. In the beginning, I was interested … Continue reading
By Shawn P. Quigley
In this blog, we will be discussing Situational, Transformational, and Transactional styles relating to leadership style and group dynamics. We will start with defining each leadership style and then look at that style for guiding a group to success. Upon completion of assessing each style of leadership, we will attempt to determine which style would be the most effective within the group. Keeping in mind that each group is different and that as Rick Curtis stated,
“When we are placed in a new situation, our old behaviors may not be appropriate. So there is a thawing period during which new behaviors/skills can be learned.”(1995)
Looking at our discussion from this perspective the leadership style we determine most effective will be based on the percentage of its’ use and success. I will then discuss the leadership style that best describes the type of leader I am and in conclusion, we will discuss an … Continue reading
Configuration auditing occurs so we can verify that what we said we were going to do actually happened. MIL-STD-973 specifies two flavors of auditing: functional and physical. Functional configuration auditing occurs when we verify that the change functions as the engineering change proposal specified it would. A change can be to hardware, software, or both (firmware).
A physical configuration audit verifies that the proper documentation for the change exists and meets standards. Such documentation may include, but is not limited to, the following:
Manuals Training material Labels The engineering change proposal itself [sometimes we see the term engineering change notice (ECN) or engineering change request (ECR)] Drawings Test documentation (including plan and results and any incident reports)
If we are talking about a major release in the automotive world, we can expect to be required to general a Production Part Approval Process (PPAP) warrant, with the associated 18 documents.
Sometimes, the physical configuration audit is more exacting and trying than … Continue reading
Configuration control is generally, what first comes to mind when somebody brings up the topic of configuration management (CM). While it lies at the heart of the system, all the components of a CM system are critical. The purpose of this component is to:
Maintain and control configuration baselines (known and defined states) Document and control change and variance Limit approved changes to those which are either required or offer important benefits Ensure the variances lie within defined boundaries Include the customer Control product interfaces (interface control document) Verifying that change proposals manage the effect of the change Control cascading changes Control coordinated changes (multiples happening simultaneously) Only approved product are affected
The key word is clearly “control.” In most cases, we will automate the process to allow computer software to help us control these changes, although we have seen usable low-technology CM systems that worked fine for small organizations. In general, we will follow a pattern:
Identify the need … Continue reading
We have hardly seen instances of this issue being discussed. We are painfully aware of the large extent we often require of configuration management because we have to work with tools in the embedded environment called “cross-compilers.” These tools allow the developer to work in a familiar programming language such as C and then produce executable code for the target processor, a processor that is often wildly different in architecture than the one on which we do the development. We have seen cases where we needed to manage the configuration of the version of the compiler, because subsequent product changes to that compiler would no longer work with target processor.
What happens if we change our configuration management (CM) support software? Aren’t we in the same situation as we are with the cross-compiler? We suggest that, indeed, we are in an analogous situation. Hence, any time we upgrade or change our CM support software, we need to many this change … Continue reading
by Jon M Quigley
Simulation activities can help evoke the requirements for a product without actually having to build the product first to learn something. Simulation need not be highly technical, though it can be. I have seen simulation of screens for an instrument cluster human machine interface (HMI) that made use of excel links to illustrate the appearance and show how the navigation worked. This was a cheap and quick way of learning how the product should work. There are more complicated ways, however, that typically employ sophisticated software and hardware. We can develop complex systems of components to simulate our product. We can use these tools to develop our requirements by testing our concepts before we build the prototype parts. We can refine our algorithms by exercising the subassembly within the context of a simulated system. We will need to confirm our models for the simulation, in fact represent the real world stimuli expected. To do that we … Continue reading
We can help with software and hardware product development. Continue reading