In the second episode of BST we look into how documentation works at BST. In short we are making use of Gitlab for almost everything.
The video has a duration of 7:20 min and gives an inside view on how we document every step at BST without killing millions of trees in the process.
Nobody likes documenting
Let’s be honest about it. The person that says they like documenting is probably not yet born. As a result quality assurance and project managers in every company fight their little battles every day to get their flock to do it. This is especially true in an industry as risk aware like the space industry where documentation is among its core values.
Pictures Pictures Pictures!
To get to a good solution we at Berlin Space Technologies believe it is key to make the documentation as easy as possible. The lower the friction the more likely it is that the engineer in pressure will actually document what you want him to do. Otherwise you will end up with a classical case of:
“hardware done first, software is written when in orbit, documentation… um later”
The first method we implemented at the inception of BST to keep the burden on our engineers low was to implement a “pictures or it did not happen rule”. As a result every step of the assembly process gets its own picture; apply glue onto the brush: picture, set the torque wrench: picture, fasten the bolt: picture.
If a picture tells a thousand words what does a video do?
In the satellite AIT we took this a step further. Since we know that people in the bunny suits should not be bothered we installed we used actual helmet cameras to document the whole process as a hands on video.
It works!
Both procedures; pictures and video have been particularly handy when trying to find errors.
“We found the reasons for several bugs of a satellite and we were able to point out exactly where it happened. “
After the fact.
The problem is that it only works retroactive. Meaning its hard to identify an error while it is happening and once the satellite in orbit its much harder to correct them. Also once you have more than just a few engineers working on a project it becomes harder to share information between people. That means two people on the same project may repeat errors already identified before. In short we realized we need a new solution.
Gitlab is for software – or isn’t it?
The software department is unsurprisingly the largest at BST and when multiple people are working on the same code – versioning is key. Therefore we rolled out Git early on and the people seemed to be (reasonably) happy. Once you use Git, accessory tools like GitLab provide you with a better ease of use.
“GitLab is a lifecycle tool that provides a Git-repository manager for issue-tracking and continuous deployment pipeline features”
And since that worked like charm and because Matthias (our CTO) was annoyed to clean up the mess that our picture documentation created he suggested to try it for hardware, too.
Gitlab Galore
First we used it in the embedded systems department. Tracking designs of software using the Git commit features and the ever so handy ticket system.
- Readme’s help to find where stuff is
- Labels help to track “Incidents”, “Projects”, “Devices”, “Todo’s”, “Departments”, “Persons”
- Templates make sure that procedure is followed from reporting to AIT
Even in the Business Development? Yes!
And since that worked so well for embedded systems, we rolled it out for mechanical design department and payload department.
We even rolled it out in business development. I have to admit that I fought it initially but it really makes my life so much easier:
- Minutes of meeting
- tracking of actions for customers
- coordinate proposal studies
Make things easier is the key to success for quality and product assurance
In the end it boils down to this, Quality assurance procedures are only easily implemented when they seamlessly integrate into the work of each person in the company. If they make the life of people easier, even better!
For us we use Gitlab. What is your solution to this problem?