Systems Engineer Journey

1. Quick Introduction to Russell
2. Introduction to HighRes Biosolutions
3. Russell's Projects in Systems Engineering
4. Responsibilities
5. Project Roadmap
6. Teams Involved
7. Requirements
8. Concept Decisions
9. Testing
10. Documentation
11. Failures

1. Quick Introduction to Russell

Hi, I am Russell. For an overview of who I am, you can check out my brief bio here.

2. Introduction to HighRes Biosolutions

HighRes Biosolutions generates data for scientists utilizing an autonomous scheduling system. They design and manufacture in-house small and large scale systems for their clients. They also created a scheduling software that coordinates instrumentation and automation while providing data to scientists.

Most of the revenue HighRes Biosolutions generates is from selling fully automated systems to its clients in the life sciences industry.

If you wish to learn more about HighRes Biosolutions, you can visit their site here.

3. Russell's Projects in Systems Engineering

I was tasked with improving Nucleus.

What is Nucleus?

Nucleus was an in-house project to standardize HighRes Biosolutions' system offerings to their customers. Traditionally, all systems were custom designed and custom built. The lead time of some custom designed systems could be 9 months or more.  To remain competitive, HighRes Biosolutions wanted to standardize their offering to lower the the delivery time of systems. The initial launch of Nucleus failed its key goals to reduce the delivery time of systems, it actually increased system delivery time, and it was not being adopted within the company.

Nucleus 2.0

Russell joined the Nucleus project as the technical owner and project lead, dubbed Nucleus 2.0, with the 3 key goals:

1. Improve System Delivery Time
2. Meet Cost Targets
3. Increase Utilization (majority of systems sold should be Nucleus)

4. Responsibilities

Project Lead

As the technical owner and lead, I was responsible for the success and failure of the projects I worked on. I took ownership and was motivated to find items that could fall through the cracks by actively engaging with members of the team, stakeholders, management, and internal customers.

Lead Discussions

I would present the project roadmap, scope, goals, requirements to management and engineering teams involved. When questions came up, I was responsible for determining and recording the resolution.

Active Listening

I needed to relearn how to listen and earn trust with members of the project. When I approached people on the Manufacturing team for feedback, I needed to let them to do most of the talking while prompting them with targeted questions. Often I needed to synthesize their input into an engineering requirement for an assembly and drive that with the engineering team.

Anything Else

A lot of 'stuff' can happen outside of team meetings and things can quickly become forgotten about. I took ownership to manage the chaos of the large project.

5. Project Roadmap

Simplify

In order to break down Nucleus 2.0 into manageable blocks of work, I created a project roadmap with the Product Manager. This roadmap served as a guide to the engineering team to make informed decisions of what was in-scope or out of scope. The roadmap featured approximately 10 different projects within Nucleus 2.0 that required Mechanical, Electrical, and Manufacturing Engineers.

Project Example

As HighRes Biosolutions grew, so did the system size and capabilities. A SCARA robot arm was typically used in the center of a system, sometimes an industrial arm was used. Many of the more recent systems featured the SCARA robot arm on a rail so it could increase the automation workspace without increasing robot count.

One of the projects within Nucleus 2.0 was to create a Nucleus "rail table" to support the robot on a rail.

The purpose of Nucleus was to provide us with a standard offering, without sacrificing the need to individually configure systems. This configuration would come in the form of sub-assemblies being placed within the larger assemblies (rail table).

Sub Assemblies

Some examples of sub-assemblies are:

• Electrical cabinet to distribute power across the system.
• Solution to route all the power cables throughout the system
• Networking and Communication
• Safety system
• Pneumatics

Each of the above sub-assembly required Mechanical and Electrical design engineers to create Nucleus 2.0 versions.

Assembly Compatibility

I created a compatibility matrix to demonstrate which sub-assemblies would go on which larger assemblies. Mechanical and Electrical Design engineers used this matrix to influence their design decisions. For example, the Electrical cabinet and power cable routing needed to be designed such that it could be mounted within a "rail table" a "static robot table" or a peripheral table which consisted of devices, instruments, and liquid handlers.

Larger Assemblies

To see some more examples of larger assemblies that would be part of Nucleus, see the following links to the HighRes Biosolution website.

• Robot Table
• Robot Rail Table
• Devices Table
• Carts

Just about any hardware that was involved in a system had a Nucleus version.

6. Teams involved in Nucleus 2.0

Nucleus 2.0 was on of the larger internal projects HighRes Biosolutions Engineering was involved in. Some key team members included:

Team Structure

• I was the technical lead and project owner as the Systems Engineer.
• Product Manager
• Technical Project Manager
• Lead Mechanical Engineer
• Lead Electrical Engineer
• Lead Manufacturing Engineer.

Depending on where we were in the project, additional mechanical, electrical, or manufacturing resources were pulled in, as well as System Design Engineers (SDE team). The SDE team was separate from the System Engineering team, their responsibilities included designing the system configurations for each customer utilizing Nucleus assemblies or custom assemblies. They were part of the system delivery process.

I viewed the Manufacturing team, Operations, and the SDE team as internal customers for this project. They would be the teams designing, building, forecasting and ordering Nucleus assemblies.

7. Requirements

Layered Requirements

As I explained in the Project Roadmap section, Nucleus 2.0 was comprised of large assemblies and sub-assemblies. I wrote different layers of requirements from:

• High Level Project Requirements or System Requirements
  • Subsystem Requirements (larger assemblies)
    
    • Sub-Assembly Requirements

Hierarchy

I wrote all Requirements using the following hierarchy

• Use Cases (UC)
  
  • Functional Requirement (FR)
    
    • Performance Requirement (PR)
      
      • Test Case (TC)

Terminology

All Requirements include one of the following three terms: MUST(or Shall), SHOULD, MAY.

Example

The electrical cabinet is an example of a sub-assembly that had requirements written for it. A requirement for this could look like:

• • FR: The System MUST support balanced power distribution.

    • PR: Electrical Cabinet MUST allow for the following number of circuit breakers:

      10 Amp	25 Amp	Total
      4	12	16

To create a requirement like this, I created a database detailing our all our systems from the previous couple of years to understand what a "typical" system's power distribution looked like. I worked with the Electrical and System Design Engineering teams to come up with what the Nucleus 2.0 electrical cabinet should offer.

8. Concept Decisions

Concept Selection Matrix

As technical owner of the project, I supported the design team (Mechanical and Electrical engineering team) in making concept decisions. I created objective criteria to score different concepts using a concept selection matrix

• Design Criteria
• Weighted Score
• Concepts

Example

Definitions:

• 1: Poor Performance
• 5: High Performance

Weights:

• Delivery time: Highest weight / most important
• Cost: High weight
• Utilization: Lowest weight

9. Testing

Product Testing

• Typically design engineers perform initial testing on sub-assemblies, assemblies, and/or sub-systems.
• The Systems Engineer (myself included) performs sub-system and system level testing (Verification and Validation).

I found myself get involved during most of the process to check-in on engineers to see how things were going.

Traceability Matrices

I was responsible for creating traceability matrices and review with team to identify which requirements are met and which are not met from product testing.

10. Documentation

Requirements

All Requirements were documented in Jira (RTM addon) and made readily available for engineering team to consume. As technical owner, if issues arose during the product development process with requirements (as they typically would), it was my responsibility to clarify or redefine requirements.

Testing

Engineers created Test Cases and Test Plans within Jira - RTM. It was my responsibility to ensure everyone was using RTM correctly and actively troubleshooted any issues that arose. Test Cases were linked back to Performance Requirements which were linked to Functional Requirements.

Training

I trained the Nucleus engineering team on how to use RTM in Jira. We were in the process adopting Jira and RTM for all our projects. This training was recorded and distributed to the whole engineering team, along with documentation I created for references and best practices.

Document Everything

My goal was to document as much as possible. People involved in projects can change, projects can be shelved and revived, and similar projects can be opened. Having documents in a readily available location for future engineers can save time and resources. During my first years in Mechanical Engineering doing Sustaining work, I recall having to reach out to the design engineers for design intent and test results often without much documentation from the design phase being available.

11. Failures

No work experience is complete without talking about failures. I was thrown into a big project for my first Systems Engineering experience. It was difficult out of the gate. There were mornings where I knew I had a tough day ahead, but I regularly showed up to do my best and learn how to improve.

Earning Trust

I had feelings of imposter syndrome when I first got in the role. Being in a leadership role with a large team for the first time, I had several emotions. Looking at how I could serve and help others on the team helped me through the early stages of the project.

Requirements

I quickly learned there is an art to writing requirements for the design engineering team. Requirements need to be specific and cannot lead to ambiguity. I loved seeing the newer requirements that I wrote drastically improved from my earlier ones.

Leading Discussions

Looking back at my earlier team meetings when I first started the role, I was awkward and a bit hesitant. I worked on my strategy to make more effective use of everyone's time.