Author: Ralphgholmieh

The Systems Design Process

The design process is usually divided in three phases: the concept review, the detailed design phase, and the determination of the requirements.

The first phase is the concept review. In this phase which should take place at about one-third of the design duration, multiple design options are considered. This phase starts with an analysis of the product requirements to get a thorough understanding of the desired functionality. This is followed by the determination of multiple design options that are identified and submitted for review. Drafts for the concept review presentation should be reviewed intensely within the systems engineers team if possible. At the concept review proper, the systems engineer should describe the design at a high level, list the options that are possible for the different part of the design, and recommend a preferred option for each one of the options. The concept review goes over the main use cases with no regard to adversarial scenarios. The concept review should be attended by the product manager, the development lead, the development/software engineer responsible for implementing the function, the system test lead, and the systems test engineer who will test the function. By the end of the concept review, agreement is reached on the main aspects of the design.

The second phase is the detailed design phase which ends with the design review proper. In this phase, the systems engineer works out the details of the design. All the adversarial scenarios and use cases are considered. Details of the algorithms are nailed down to the level of exhaustive flow charts and call flows. Communication with the development and test engineers is encouraged to get early feedback on the design. Cross team communication may be needed to request changes to modules outside the responsibility of the systems engineer. It is possible that when working out the details of the design, some unexpected difficulties may be uncovered which could lead to modifications or even reversals of decisions taken during the concept review. The design review should be attended by the product manager, as many members of the development team as possible, and as many members of the test team as possible. This wide attendance will ensure that experts in all aspects of the system will be present and will bless or counter the design. By the end of the design review, agreement is reached on all aspects of the design.

The third phase is the writing of the requirements. This phase usually takes one to two weeks. The systems engineers writes and shares the requirement, then schedules the review about a week out to give the reviewers ample time to provide comments. Requirements are important because they will serve as milestones for the development and test teams for implementing and testing the function respectively. This phase is usually straightforward for the experienced systems engineers but may lead to multiple rounds of requirements reviews for the novice systems engineer which may struggle in the best way of describing the design through simple shall statements. Furthermore, in this phase, some reviewers who had first seen the design in the design review, may provide further comments on the detailed design. By the end of this phase, the design and requirements are set.

The length of the different phases may vary. However, a good time distribution is 1/3 to 1/2 of the time on the concept review, 1/2 the time on the detailed design phase, and about 2 weeks for the requirements review. A lengthier concept review may lead to a more detailed design and may shorten the detailed design phase.

The output of the concept review is always a presentation. The output of the design phase may be a presentation or a word document. Presentation are best used in dynamic environments with excellent communication between the systems, software and test teams. Word document are best used in more formal projects with either an emphasis on formal design, or a looser integration between the systems, software and test teams. In the latter case, a more detailed description will lead to clearer communication of the design.

On Simulations and Analysis

Simulations are programs that emulate the behavior of the finished system allowing the study of certain performance aspects for optimization and performance evaluation.

Early on in my career, when I was a green systems engineer, I used to throw myself into huge end-to-end simulations that tried to mimic every aspect of the system. At some point, I wrote a TCP stack simulator and incorporated it into an end-to-end 3G cellular system. We were studying resource allocation at the base station level and wanted to understand the impact across the stacks for http and email use cases. I did obtain good results but it was a painstaking effort. Writing large detailed simulations is like developing a system with the same level of complexity as the real system. The real system will have dozens or hundreds of engineers working on it and will still be full of bugs. So, this endeavor should not be taken lightly. Developing a large simulation is doable in large companies where a decision may be made to support such a system simulator for the benefit of a large number of evaluations. The resources will then be committed to maintain the simulator. Branches can be created for specific evaluations. Still, a friend of mine used to say that the real proof that you understand a large simulation is finding a bug in it.

As I became more experienced, I drifted toward simpler simulations based on high level mathematical languages such as Matlab. And, before writing any code, I always spend time trying to identify the key mechanisms and determining the minimum level of complexity required to mimic the studied behavior. As part of this pre-study, one may find closed form solutions that can supplement the simulation results and provide insights into the tradeoffs of the parameter settings. It is surprising how many systems and development engineers are reluctant to apply simple math to analyze the work they are doing. Once, an x or a y is shown in a presentation, people feel overwhelmed. So, always explain your work as simply as possible and with a lot of figures and detailed steps. You may be asked to skip the details, but the details will be there for the curious.

So, to summarize, the best approaches to simulation and analysis are:

  1. Whittle down the mechanism you are evaluating to its simplest expression.
  2. Try to find a mathematical model that fits the mechanism.
  3. Simulate using a simple and powerful language. This step may be applied even if a mathematical model is found in step 2.
  4. If the above does not work and if a large simulator is already developed, then use that simulator after modifying it for your purposes.
  5. If all else fails, ask for resources to develop the large simulator described above. Proceed with care.

The two principles guiding this approach are ones that I learned from an old systems engineer:

  1. The KISS principle: Keep It Simple, Stupid!
  2. And, the SWP principle: Steal With Pride i.e. reuse existing work whenever possible.

Initially, I scoffed at these principles. After all, the Golden rule is that there is no Golden rule. However, these two principles can be applied to all areas of systems engineering and especially, in my case, to simulations and performance analysis.

I will give one example of a simple derivation that has served me a lot for studying the contention between two periodic procedures. Consider a primary process running every 470.69 ms for 20 ms, and a secondary process running every 320 ms for 80 ms. The primary process has priority and will thus preempt the second process. We wanted to consider the impact of raising the priority of the secondary process. Thus, the secondary process would now preempt the primary process. We ran some simulations and determined that the primary process would not execute 23% of the time. However, I noticed a simple derivation that provides more insight into the error rate and the pattern of errors.

For simplicity, assume that the primary process occurs every 470 ms. As may be seen later, the timescale of evaluation was 15 seconds and the drift of 0.7 ms every 470 ms has minimal impact.

Consider, without loss of generality, that the primary process occurs every M*470 ms for 20 ms where N is an integer, and the secondary process occurs every N*320 ms for 80 ms where M is also an integer.

For a given N, the primary process is preempted if there exists an integer M such that there is overlap between the 2 processes. The existence of M means that there is an occurrence of the primary process that overlaps with the secondary process at N. Formulaically:

An integer M exists such that N*320 – 20 <= M*470 <= N*320 +80,

or, N*32/47 – 2/47 <= M <= N*32/47 + 8/47

Consider the fractional part of M*32/47, it is equal to (M*32 mod 47)/47. Since 32 and 47 are mutually prime, N*32 mod 47 will produce the integer numbers 0..46 within a cycle of 47 consecutive values of N (i.e. within 47 occurrences of the secondary process). The fractional part will take on the values 0, 1/47, 2/47, .., 46/47. An integer M exists when the fractional part is either 39/47, 40/47, .., 46/47, 0/47, 1/47, 2/47 (this can be verified by plugging the values into the equation). Thus, within 47 consecutive values of N, the number of preemptions will be 11, i.e. 23% of the time. The pattern repeats every 47 cycles and takes 15.04 seconds.

Thus, we can easily extend the analysis to any 2 periodicities or length of activity without the need for additional simulations. Furthermore, the simple math showed us the error pattern repetition periodicity allowing us to set testing durations, develop detection algorithms, and more.

The above little problem now serves as one of my favorite interview problems. Multiple birds, one stone!

Systems Engineering

Hi there, I am a systems engineer with more than 15 years of experience in the wireless communications industry. My plan is to share in this blog the lessons I learned throughout my career.

Systems engineering is the art of defining the interactions of a module within a system such that all the modules in said system work end-to-end harmoniously.

The principal method for defining these interactions are requirements. Requirements are atomic and testable statements that must be implemented by the module in question. Other important tools at the disposition of the systems engineer are the architecture description, call flows, flow charts, and use cases.

A factotum systems engineer may design a system behavior, simulate it, file patents to protect any new ideas, identify standards changes or product requirements changes, support the implementation of these changes (in standards or at product level), write the systems design document, support the software team in the implementation, review the software design from the software team, review the test plan from the test team, and finally go over the functional, and performance test reports for final validation.

I have been lucky to have worked in all the areas described above. I have always been a very technical systems engineer. My one big weakness is the lack of political awareness. A great systems engineer builds coalitions to push his or her vision of the product. In my case, I have always tried to push my agenda on a purely technical basis, so I do not consider myself a great systems engineer. However, in this case, good is more fun than great, so I’ll concentrate on these prosaic aspects of my craft.