At Demcon, I was a Mechatronics Systems Engineer focusing on both Control and Systems Engineering. This is done in one project with the goal to create a surgery grade medical device (specifics intentionally left out). The control aspect involves controller design, proofing safety and stability, supervision of other Control Engineers and testing. For System Engineering, I am involved in requirement definitions, client contact, concept documentation and failure mode analysis. Languages used: Matlab/Simulink, Python
Within the project, the ISO 13485, ISO 14971, IEC 60601 and IEC 62304 standards were used. Of these, I followed a course in usage of IEC 60601.
Situation Overviews using STAR methodology
[2022] Meeting client expectations
Situation – The control of the surgery device was not meeting the client expectations. The requirements with the client were met, but the results from the field trial returned 20 issues related to performance. The client was unsatisfied and had given us three months additional time to fix these 20 issues outside of the requirements.
Task – My task was to create solutions for these issues, together with the rest of the control team, to lead the discussions with the client and restore client trust.
Action – Together with the team, we divided these 20 issues into 6 issue categories, after which I found the root cause and solution to 5 of these issue categories. I made the initial implementation after which I handed 4 of these to colleagues to finish up (with me taking a supporting role) and further focused on the remaining solution which was the most related to performance and would provide the most drastic improvement. This solution focused upon defining the related physical characteristics and updating the current estimation algorithm accordingly.
To restore client trust and ensure satisfaction, I proposed to schedule periodic lab testing together with the client where also unfinished solutions were shown. This way we would have faster iterations, the client would have more say in the final solution and the client would grasp the inner workings of the final solution better.
Result – As a team, all 6 issue categories were solved together with the underlying issues. All of my initial solutions were still used in the end product, only requiring minor tweaks. The issue category fully picked up by me, resulted in a performance increase in all benchmark tests, with the most critical benchmark tests showing a performance increase of 300%. The client was very satisfied with the way they were involved in testing and the way of work was updated to include more lab testing together with the client to ensure future satisfaction.
[2022] Proof of safety
Situation – Since the created product was a medical device, patient safety must be guaranteed with regards to a single point of failure (as per medical standard). This proof had to be created.
Task – My task was to choose a method of proofing safety, create a proper set-up and perform this method.
Action – Initially, I set up a couple of examples of potential methods (lead engineer helped in providing theories), after which the choice was made with the team to perform an FFMEA (Functional Failure Mode and Effect Analysis). I set-up and performed the FFMEA by first relating the hardware design to specific functionalities. Afterwards, I described the failure modes of these functionalities. Following, I created the effect analysis of these failure modes based upon knowledge of the software implementation.
Result – Based upon the FFMEA, follow-up tickets were created to improve safety. After these tickets were solved by the team, the product could be proven single point of failure safe.
[2021] Impact analysis of hardware changes
Situation – To improve performance, hardware changes (different radius of tubing) were proposed by the team. A prototype of this hardware had to be created and an analysis of the performance changes had to be made.
Task – I was tasked to create the hardware changes, perform the performance analysis and report the differences such that the client could make a decision based upon the report. All steps were performed under supervision of the lead engineer.
Action – The different tubing could be made by disassembling the current tubing sets and replacing with the provided tubing. Afterwards, I analyzed the tubing for changed parameter values, such that I could update the control algorithm. At this point, I performed exploratory testing to clearly identify (unforeseen) up- and downsides. Following, the old and new tubing were compared using benchmark tests as well as non-benchmark tests which more clearly could show the differences between the tube sets. The results were combined in a report, which concisely described the changes to the client.
Result – The client accepted the hardware changes without needing further testing.