To parameter or not to parameter?
In every multi-disciplinary system, at one point or another, we are faced with the problem of which parameters are systematic, which are to be defined in the field, which are to be calibrated during production and which are left only for R&D. Furthermore, in higher generation machines we tend to find system parameters and variables in the configuration files which no-one really knows what they stand for or control, with the exception of perhaps a long retired engineer that is currently lying in the sand on an exotic beach in a hot and humid country somewhere on the equator 
.
In this post we will cover what are system parameters and why they are so important and obviously how and when to define and set them.
What are System Parameters & System Configuration
Official system parameters definition is hard to come by. There are many definitions out there, but most of them refer to a discipline’s system parameters and do not really convey the message for multi-disciplinary systems.
Furthermore, the definition of system parameters is a bit tricky since it depends on where to draw the line as to where a component or a sub-system ends and the system starts.
To avoid the complexity of sub-system separation and definition I will use a non-orthodox definition of my own invention as follows:
A System Parameter is any configuration variable that is set or approved by the System Engineer, Integrator, Manufacturing Engineering or Application Engineer during the product life-cycle after the system’s hardware is finalize (late integration stages). Changing or setting System Parameters is to be done via simple file editing or via a dedicated configuration tools and does not require any intervention from R&D teams such as SW compilation and upgrade or firmware update.
To complete the definitions section for this post, let’s also define System Configuration:
A System Configuration is a unique set of System Parameters used in systems in the field, in production\manufacturing or in R&D to serve a specific purpose of system performance.
Let’s look at these two definitions closely. First and foremost, system parameters are changeable by a text editor or a dedicated configuration tool. This part is paramount! If needed a system parameter may, of course with the approval of the relevant engineer, be set by a repair technician.
The disciplines System Engineering, Integration, Manufacturing Engineering and Application Engineering are the technical disciplines that have the authority and responsibility to change configuration in the system level according to their or their client’s needs, respectively. The timing of the approval \ change is also important – if the change is made deep inside the research stages or in early integration, they are not considered a system parameter since these are still stages where the system is being built. There is however a subtlety of the timing in integration: towards the end of integration the team tends to concentrate in fine-tuning of the system performance. In these particular phases of the development process, the ship is headed in the direction of fulfilling the System Requirements as close as possible to the Product Requirements but these may change if a new market is to be introduced to the client. In such cases this particular fine-tuning process will be repeated but we all would like to refrain from code editing or re-development only to adjust the system’s performance to a certain client’s needs.
Evolution of System Parameters
The evolutionary process of system parameters should be quite simple: we start with as many parameters possible to be able to control everything during the development process and as we progress through the different stages of development we cross parameters off the list and make them system constants. In a properly conducted process we should have a meeting of all relevant parties – R&D, Support, Product, Manufacturing – to decide if a certain parameter (or set of parameters) should be hard coded of controlled in config file.
In practice, it is a bit more complicated: First, usually there are a lot of parameters we forget to define as “controllable” (or on the other hand, we did not even know we had them in our system or needed them in the requirements phase). Try to recall how many times you approached the SW or HW team leader and asked him\her to expose such and such parameter to be controlled from the outside only to discover that it is buried deep inside whatever wrapper that wraps it and you have to restart the whole system each time you change this parameter and many other technical obstacles only to change the speed of a motor . Second, we are so overloaded with work that crossing parameters off the controllable parameters list is probably one of the last items in our to-do list. And third, we are afraid to remove items from a parameter list, simply because we do not know if there will be a future use for such a capability.
Solution: Parameters’ Visibility
The proper solution that is practiced more or less everywhere is parameters’ visibility, with 4 different visibility levels for setting and changing parameters:
0 – Technician Level
Those parameters that effect the system in the client level for example: as location related parameters, network parameters (IP, hostname etc.), environmental limits and in-field calibration parameters such as background noises, baseline values, nominal encoders \ motor location etc.
1 – Manufacturing Engineering Level
Those are parameters, obviously on top of technician level parameters, that when the machine is assembled on the assembly line goes through the process of alignment and calibration or configuration setup,. These parameters would be alignment parameters (pixel size and FOV in optical systems, laser alignment variables, motor variables etc.), system configuration (110V \ 220V electrical compatibility, certain features on\off, HW models etc.), licenses and so on.
2 – System Engineering Level
In most cases this is the highest level that allows practically changing each and every parameter in the system. Usually in R&D integration stages the integrators get this highest level of parameter access as well.
3 – Master Yoda Level
In highly complex systems where there are many algorithmic parameters or very high-end control feedback systems that the R&D teams may decide that there are certain parameters in which changes of these settings are allowed to be made only by the gurus of those particular fields. This usually happens as a precaution after a very severe case of wrong configuration reached the wrong place and it took a lot of effort to identify what happened and this sometimes at enormous cost as well as reputation impact These are the most complicated and difficult to understand aspects of the system. If you have such parameters with this visibility level, make sure to have them well documented for future generations.
With this visibility solution in mind, the System Parameters Evolution Process looks like the following:
System Configurations & Configuration Management
The discussion about system parameters would not be complete without having a word or two about system configurations.
From early research stages, even if we do not treat them as such, we have system configurations: setpoints of the lasers, control parameters of motion, sensor gains and whatever.
Especially in experimental machines, where a lot of different people with different agendas use the system on an hourly basis, all parameters are subject to change. There is nothing more frustrating than arriving in the morning to your system and starting a procedure only to discover at the end of the day that it had a different configuration than the one you set the day before and someone changed it without prior notice.
We established earlier what a System Configuration is. Let’s assume that at one point or another there are a few system configurations for example: measurement, alignment, long testing etc. It is important to have as few system configurations as possible. Maintaining configurations is a tedious task which eventually may end in the wrong configuration on reaching the wrong client and this especially when there are multiple configurations.
A very important aspect is, on the one hand to verify that no-one changed any system parameters in a certain configuration and on the other hand, to make sure that parameters that were changed and needed to be updated in a certain configuration do not get overridden by the old version of that particular configuration.
Configuration Management Tools Save Time and Effort
There are two ways I would like to briefly detail here for system configuration management. The obvious first method is to use your pick of configuration management tool. There are many tools to choose from for this task, from open-source projects like git only to cover the parameter files and up to full blown tools like SalesForce that allows you to control each and every client’s configuration including, HW, as well as other aspects of the client and sales. Do not forget to give a meaningful comment to each configuration. “Ver 1.2 May-5th morning” will not tell you anything useful in 2 weeks’ time! If it is a dedicated for a client or it has special features write it down. And, above all, if some features were removed in that configuration, document it!!!
BTW, configuration management, in the hectic days of integration in a multi-disciplinary system when every morning we install a new piece of equipment from different batches and different manufacturers, is a must and there we should include also the different hardware models in it. Without going too deep into it, at this stage you should have a detailed table for each machine out there with all the configuration and changes history and zealously force everyone to keep that table, no matter what, updated at all times. A good integration engineer will do this task without you asking for it.
The second method is mainly for R&D purposes when many system parameters and configs get changed very frequently. Have a set of sanity tests available for each set of features or sub-systems. When a relevant sanity test is done before starting any activity on the machine you can be certain that at least for that particular feature the parameters and configuration are correct.
System Engineering and System Parameters as an Art
In my opinion, the pinnacle of proficiency in System Engineering is the ability to forecast how the early and advanced configurations of the system will look like and accordingly define the list of system parameters to be implemented by the different disciplines in the team. Even though it seems insignificant (only a matter of a parameter here and there), we could assess the whole system engineering work and design of the project through the System Parameters and how the System Engineer has approached and defined them.
If we dive into the flow of this art that the System Engineer should master it starts with understanding the whole flow of the development and\or manufacturing of the system, continues with the correct (!) assessment of the arrival schedule and timing of all the features and pieces of hardware into integration \ implementation, form expected configuration list, understand every dependency of the error budget and finally, derive which parameters are needed for control per configuration and which parameters are needed to transit from one configuration to another.
This deep understanding of each and every aspect of the system, while planning correctly the different configurations which most of the time are incremental to previous systems or prototype generations, makes this task so complicated. Add to that the feature and hardware arrival sync with all other development issues you get the real essence of the System Engineering role, indeed the task that no other discipline is required or expected to perform.
BTW, I have noticed over the years that the System Engineers and Technical Leads that got the system parameters right in a certain project, usually also got it right in every project from that point onward.
I would like to end with this optimistic note. In this post I tried to convey how important system parameters are and to map the process of their evolution. I truly hope it will help you become a better system engineer or if you’re not one, know what to expect from your technical lead.