BE1031204B1 - MANUFACTURING PROTOTYPES OR SMALL SERIES OF ELECTRONIC DEVICES - Google Patents

Abstract

Method for manufacturing an electronic device using a computerized development process with special task management which allows highly parallel development and verification processes, with the use of extracts, with the use of checklists, with the use of continuous improvement of the checklist.

Description

MANUFACTURING PROTOTYPES OR SMALL SERIES OF ELECTRONIC DEVICES

Technical area

The present invention relates to a method for manufacturing electronic devices, in particular prototypes and small series.

Prior art

The development and manufacturing of electronic devices in small series is complicated, time-consuming, error-prone and therefore expensive. Depending on the specifications of the new electronic device, it is first necessary to develop the circuits with all the blocks and their components. This is normally carried out by an electrical developer. Once the circuits are ready, the mechanical developer and software developer can work on finalizing the product. The mechanical developer works on the mechanical realization of the device, for example a housing, wheels, a movable arm, etc. The software developer works on implementing the functions of the electronic device into programmable components. However, some circuit errors will only be recognized by the mechanical team and/or software team, so such an error requires a circuit redesign and stops the entire process.

However, the circuit development process alone is also very serial and time-consuming. Circuits are normally designed, then checked for errors, and finally corrected. This takes a lot of time and can block mechanical design development and software development.

Due to the high risk of errors in the development of complex software programs, the software industry has developed development processes and software that are used to develop and test/verify in parallel. However, these processes and software are not easily applicable to circuit development.

Brief summary of the invention

The object of the invention is to reduce development time while at the same time reducing errors in the development and manufacturing process.

According to the invention, this object is solved by a method of manufacturing an electronic device according to claim 1.

Over the years, inventors have developed a very efficient development and manufacturing process that allows them to develop new, reliable electronic devices in a much shorter time than the processes used in the state of the art.

This was achieved by the combination of a plurality of small measures which together significantly reduce development time and development errors. The special task management used for electronic development, which enables a highly parallelized development and verification process, has significantly reduced time and errors. In particular, the distinction between the “done” and “to be verified” task categories allows the development process and the verification process to run entirely in parallel without any waiting time until the verification process is completed. In particular, in combination with a standardized checklist-based verification process that also involves software developers in the electronic development verification process. These small measures helped detect errors at a very early stage and not just when the software is finally downloaded to the manufactured electronic device. Additionally, continuous improvement of the checklist based on mistakes/lessons learned at the end of each project has significantly improved this process. Finally, the use of extracts accessible by all users and therefore used in a harmonized manner makes it possible to obtain frequently used and tested electronic modules. After each project, new snippets are defined, if these can be used for future projects by the development team. Early detection of errors helps avoid costly and time-consuming error detection, error correction, or worse, redevelopment and remanufacturing.

The dependent claims refer to other advantageous embodiments.

When the electronic device also involves mechanical parts, the same process is applied for mechanical development, which further improves the process. In this case, interaction between the software, electronics and software team for the verification process of electronic development and/or for mechanical development has proven to be very effective in detecting errors at a very early stage.

Other embodiments according to the present invention are mentioned in the appended claims and the subsequent description of an embodiment of the invention.

Brief description of the drawings

Figure 1 shows an example of a functional diagram of the computer system according to the invention.

Figure 2 shows an example of a functional diagram of a task management module according to the invention.

Figure 3 shows an example of a functional diagram of the manufacturing process of an electronic device.

Figure 4 shows an example of a process block diagram for electronic development.

Figure 5 shows an example process block diagram for mechanical development.

In the drawings, the same reference numbers have been assigned to the same or similar element.

Detailed description of an embodiment of the invention

Other characteristics and advantages of the present invention will emerge from the following non-limiting description, and with reference to the drawings and examples.

An electronic device includes electronic components and software. Electronic components normally include at least one circuit board, sometimes even multiple circuit boards. Electronic components may further include other electronic components not installed on a circuit board such as motors, sensors, actuators, etc. Electronic components, normally

At least one circuit board normally includes at least one programmable component such as a microprocessor, a CPU, an FPGA, etc. The software of the electronic device includes at least the software for the programmable components of the electronic device, i.e. the embedded software. The software may further also include software parts which are not installed on the electronic device (external software), but which are used outside the electronic device, for example in a computer or server used to control or communicate with the electronic device (in one or both directions). This could be, for example, a user interface, for example an application on a mobile phone. Thus, the software includes at least the embedded software and may optionally also include external software.

Preferably, the electronic device further comprises mechanical components. In a simple case, the mechanical components may simply be the device housing. In a more complex case, mechanical components can refer to moving parts of the electronic device, for example motion control parts such as wheels, chains, thrusters, etc. or robotic arms. However, it is also possible that the electronic device does not include mechanical components, for example an electronic card.

The manufacturing of the electronic device also requires the development of the electronic device. This development is carried out by a development team.

The development team includes a plurality of developers. Developers are people. The development team includes an electronics development team and a software development team. If the electronic device also involves mechanical components, the development team may additionally involve a mechanical development team.

The electronics development team includes at least two electronics developers. The at least two electronic developers are separate developers from the development team. The software development team includes at least one software developer, preferably at least two software developers. In the latter case, each software developer is a separate developer from the development team.

The mechanical development team includes at least one mechanical developer, preferably at least two mechanical developers. In the latter case, each mechanical developer is a separate developer from the development team. The developers of the electronic, mechanical and/or software development team are preferably separate developers. However, it is also possible that one developer from the development team works in two or even three development teams. So developers from two or three of the electronic, mechanical and software development teams may also be the same developer.

Figure 1 shows a computer system 10 according to the invention. The computer system 10 may be accessible to different users. The computer system 10 is preferably implemented by a client-server architecture which allows users to work on client devices (e.g. computers) on the computer system.

The data relating to development and manufacturing is preferably stored in a data storage 14 which is accessible by all users (or customers). Each developer on the development team corresponds to a user on computer system 10. This means that each developer on the development team has user credentials (usually a username and password) to access the computer system 10. User credentials not only control access, but also know which user is performing which action. The users of the electronic development team are hereinafter called 5 electronic users. The users of the software development team are hereinafter called software users. The users of the mechanical development team are hereafter called mechanical users. Obviously, if a developer works in two or more electronic, mechanical and software development teams, the corresponding electronic, mechanical and software user may also be the same.

The computer system 10 includes a plurality of software modules. The software modules include a task management module 11, a circuit planning module 12 and a communication module 13. The different software modules can be implemented in one software program or in a plurality of separate software programs.

In the latter case, each software program could have a different user credential for the same developer. For reasons of simplicity but without any limitation of the invention, a user (electronic, software or mechanical) is simply designated as the same user. It is however clear that this same user (electronic, software or mechanical) can be considered as a different user for different software modules, for example the same developer can have a user credential for the communication module 13 (for example example, an electronic messaging program) and another for the task management module 11 and yet another for the circuit planning module 12.

Figure 2 shows an example embodiment of the task management module.

The task management module 11 is software that allows you to manage T tasks. The tasks

T can be generated by (each of) the user(s) and moved between different task categories. A task normally refers to a certain task in the development of the electronic device. The task categories refer to the state of development of the particular task T. The task management module 11 includes the following task categories: “to do”, “in progress”, “done”, “to check” and “verified”. The name of the task categories is not relevant and should not limit the invention. The task category should be defined by its purpose of use, as will be explained later. Users can move a task from one category to another (for example using the user input means of a computer). The user can move T tasks preferably by dragging and dropping between different task categories. However, it is also possible for the software module 11 to automatically move the tasks T, for example when it detects that a user is working on a special task T.

The “to do” category of tasks refers to all tasks that the development team needs to complete. Thus, all T1, ..., T4 tasks classified in the “to be done” category are tasks that remain to be done or developed. The completion of a task that is classified in the “to do” category has normally not yet started. When a developer starts working on such a task in the “to do” category, the task is normally moved to the “in progress” task category.

The “in progress” task category refers to all T5 tasks that are currently under development by the development team. So the “in progress” task category includes all T5 tasks that a developer on the team is currently working on. "Currently working" means that the developer has started the task, but has not yet completed it. This does not necessarily mean that the developer is working on this task without interruption. Once the task is completed, the task is moved to the “done” category.

The “done” task category refers to all tasks T6, T7, T8 whose development has been completed by the development team, but whose verification process has not yet started (and obviously not yet completed). So, the “done” task category includes all tasks T6, T7, T8 on which development work is completed according to the developer of the development team responsible for task T6, T7, T8.

The task category “to be verified” refers to all tasks T9, T10, T11 for which the verification process can begin. The difference between the “done” and “to be verified” category proved to be very important for the effectiveness of the development process. Since many tasks are closely related, especially in electronics, checking a single task is often very inefficient. So, by having two categories, "done" and "to be checked", the developer can wait for a group of tasks to be completed and move them as a group (check group) of tasks from the "done" category into the “to check” category. This makes the verification process much more efficient because the developer can flexibly decide whether, in a particular case, it is more practical to verify a larger number of tasks together (with the disadvantage that verification can only start later later with the verification process and the feedback comes later) or select a smaller group which might require more verification process of different groups but provides the verifier's feedback earlier. In addition, the two categories of tasks make it possible to freeze a certain state of development (for example by creating a circuit plan of the current state of circuits linked to the tasks to be verified. During this verification process, the electronic developer working on the circuit plan can continue working and move completed tasks into the "done" category without confusing the verifier with additional tasks to be checked, but not represented in the frozen state of development. Without this differentiation between these two categories, It would be up to the verifier who does not normally know the details and interactions of these tasks, (i.e. with how many tasks T) to verify the tasks in the “done” category.

Furthermore, without this differentiation, the electronic developer would not be able to continue working until the verification process is completed. Thus, this simple measure improved the parallel work of developers and reviewers. If the verification process shows that one of the verified tasks has a problem, the respective task is returned to the “to do” category. If a task was deemed correct in the verification process, the task is moved to the "verified" category.

The “verified” task category refers to all tasks that have been developed and for which the verification process has confirmed the correct development of the task

The task management module 11 allows efficient division of a development into several small tasks and parallel development and verification of the tasks.

The task management module 11 makes it possible to create such a task management environment described above for different development modules, for example different electronic modules as will be explained in more detail below. This allows working in parallel on different development modules, perhaps by different developers.

The task management module 11 can be created for example with the phabricator software, or jira, or Trello, or Microsoft planner with the correct configuration of the task categories as explained above.

The circuit planning module 12 is a software program for planning the electronic components of the electronic device, including planning circuits and circuit boards. This program can be for example Altium or Eagle, or

Mentor, or Kicad.

Communication module 13 is a software program that allows communication and data exchange between users. The communication module 13 may be a simple electronic messaging program or may be a chat program. The communication function of the communication module 13 can also be integrated into one or more of the other programs, for example in the task management module 11.

Software editing module 15 is software development software. The software editing module 15 can also include a plurality of different software development software programs depending on the type of software to be developed (type of programming language, type of programming (text, visual), type of components to be programmed, etc.).

The mechanical planning module 16 is a software program for developing the mechanical components of the electronic device. This may include CAD software for planning mechanical parts. As also mentioned above, the module 16 may also include a plurality of software programs for the purpose of planning the mechanical components of the electronic device.

Figure 3 shows an embodiment of the manufacturing process of such an electronic device with its different stages.

In step S1, the specifications of the electronic device are defined by the development team. Specifications are developed from the functional requirements of the electronic device. The specifications represent a list of high-level technical requirements which normally do not already foresee the choice of further development, the way in which this technical requirement is realized.

In step S2, development objects are defined based on the defined specifications. Preferably, the development object for each development team is defined, an electronic development object to be developed by an electronic development team, a software development object to be developed by a software development team and a mechanical development object to be developed by an electronic development team. developed by a mechanical development team.

Steps S1 and/or S2 are preferably carried out by the complete development team, i.e. by the electronic, mechanical and software development teams so that the development object and/or specification are defined correctly and with the participation of all teams.

In step S3, mechanical development is carried out based on the mechanical development objective. Mechanical development is carried out by the mechanical development team. Step S3 is optional. If the electronic device does not involve any mechanical components, step S3 can be avoided. The mechanical development ends with a mechanical plan of the mechanical parts of the electronic device.

In step S4, electronic development is carried out based on the electronic development objective. Electronic development is carried out by the electronic development team. Electronic development ends with a circuit plan of the electronic device.

In stage S5, software development is carried out based on the software development objective. Software development is carried out by the software development team. Software development ends with software to be installed on the electronic device, more precisely on one or more programmable components of the electronic device.

Steps S3, S4 and/or S5 are preferably carried out in parallel, but could also be carried out one after the other in any order.

Once the mechanical development of step S3 is completed, the mechanical part(s) is/are manufactured in step S6 based on the mechanical plan. The manufacturing of mechanical components is preferably carried out by 3D printing. In this case, the mechanical plan also includes the manufacturing files for printing the mechanical parts (which must be printed by a 3D printer, or ordered from a supplier of custom mechanical parts). In a simpler case, the manufacturing of some of the mechanical part(s) can also be done simply by ordering them, if they exist as commodity products, e.g. wheels, axles.

After the electronic development of step S4 is completed, the electronic components are manufactured in step S7 based on the electronic plan. Electronic components normally involve one or more circuit boards. In the case of multiple circuit boards, the different circuit boards may be manufactured at different times, for example when the development of a first circuit board is completed (while a second is still under development), the first can already be manufactured. The circuit board is manufactured by common circuit board manufacturing techniques which normally involve manufacturing the circuit board with the leads, vias on the substrate. After the circuit board is manufactured, the electronic components are assembled on the circuit board, usually by surface mount technology or through-hole technology. This step is usually performed by the engineering team by sending the circuit plan to a circuit board manufacturer. In this case, the circuit plan has all the circuit board manufacturing files, such as Gerber file(s), NC drill file(s), etc. The circuit board can be rigid or flexible or a combination of both.

Once the at least one mechanical part is manufactured in step S6, the mechanical part(s) is/are validated to detect errors. This includes visual inspection of manufacturing errors, but also testing compliance with the specifications of the defined electronic device. Part of this mechanical validation can also be carried out after the partial or total assembly of the mechanical part(s), or even after their assembly with the electronic parts (circuit cards).

Once the at least one circuit board is manufactured in step S7, the circuit board(s) is/are validated to detect errors. This includes visual inspection of manufacturing errors, but also testing compliance with the specifications of the defined electronic device. Part of this electronic validation can also be carried out after the partial or total connection of the circuit cards, after the assembly of the at least one circuit card with the mechanical parts and/or after programming.

Once the S5 software development is completed, the electronic device or the programmable component(s) thereof is/are programmed with the software developed in step S10. The component(s) may be programmed before assembly or after assembly on the circuit board, preferably after assembly. In step S10, the electronic device is also assembled, once steps S6 and S7 are completed. This includes electronic assembly, for example connecting the different circuit boards, connecting the circuit board with other electronic components, for example motors, etc. In particular, if there are mechanical parts, the mechanical parts are assembled with the electronic components to form the electronic device.

Figure 4 now shows the S4 electronics development process in more detail.

In step S31, the electronic blocks of the electronic components of the electronic device are defined on the basis of the electronic development object. Electronic blocks are functional blocks of the circuits of the electronic device. The common blocks are a power supply block to manage the power supply to the electronic device, a control block, a processing block, a communication block, a block for a certain sensor, etc. The main electronic components used in the blocks are defined in this step. For example, for a processing block, the processing component used is defined. For example, for a communication block, the main communication chip used is defined. This step also defines the power supply, including the power supply structure and its sizing (i.e. required power, voltage and current).

The power supply must be set based on the electronic components selected at this stage in the electronic device. In addition, the interactions between the blocks and their components are taken into consideration in this step, in particular their compatibility. This step is defined by the members of the electronic development team and the software development team and, where applicable, the mechanical development team. This allows you to quickly select components suited to the needs of all development teams. Thus, the team can consider whether the component has the necessary electronic capabilities, has the required mechanical capabilities, and can be programmed to perform the functions necessary for the electronic device based on the objectives or specifications. This step results in a functional diagram defining the different blocks of electronic components of the electronic device on the basis of the electronic development object.

In step S32, the electronic development object and/or the block diagram is divided into a plurality of electronic modules. Each electronic module preferably corresponds to a physical unit of electronic components which can be easily manufactured independently of the other electronic modules. Preferably, each electronic module corresponds to a different circuit card. However, it is also possible (for example, for larger circuit boards) that a circuit board can be divided into two or more electronic modules. This step is preferably carried out by a developer from the electronics development team, preferably by at least one lead developer from the electronics development team.

The following steps are described for an electronic module. It is obvious that the description is also valid for more than one, preferably for all electronic modules.

In step S33, a task environment is generated in the task management module 11 for the electronic module. This is done by one of the electronic users. For example, the electronics user corresponding to the lead developer responsible for the development of the respective electronics module can create the task environment of the electronics module. It is also possible that one (an electronics user of) project manager of the electronics development team generates the task environment for all electronics modules which are then possibly developed by different electronics developers. However, software developers and/or mechanical developers can also generate one or more task environments.

In step S34, the electronic module finalization tasks T are defined and generated in the electronic module task environment. The generated tasks T are placed in the “to do” task category. It is further possible to have an additional task category for tasks that are planned, whose development is not necessary now. In this case, the generated task can also be placed in this additional task category, if task development is not immediately necessary. The task would then be moved to the “to do” task category, when the task needs to be developed and/or becomes relevant. Thus, placing the generated task in the “to do” category should also include the embodiment where the generated task is placed in the additional task category and moved to the “to do” category. If this additional task category does not exist, the task management module 11 could also automatically place newly generated tasks in this category. The generation of tasks T is carried out by one of the electronic users. For example, the electronic user corresponding to the lead developer responsible for the development of the respective electronic module can generate the tasks of the task environment. It is also possible that a (electronics user corresponding to) project manager of the electronics development team generates the tasks of all task environments for the electronics modules. It is obviously also possible that one, some or even all of the tasks for one, several or even all of the task environments of the electronic modules are/are created by a mechanical, software and/or verification user. It is also possible that the tasks are partially pre-generated, that is to say generated automatically. For example, some tasks that are always the same for each circuit board can be automatically pre-generated when generating the task environment.

In step S35, one (or more) of the electronic developers starts working on one (or more) task(s) T of the tasks in the “to do” category. When he/she starts working on task T, task T is moved from the “to do” task category to the “in progress” category. This allows other developers to see which tasks are already in development and which remain to be done. Thus, a highly flexible development environment can be created in which several developers can work in parallel on different T tasks of the same electronic module. The work on task T involves the creation of a part of the circuit plan of the electronic module which is linked to the task T. This part of the circuit plan is carried out in the circuit planning module 12. The part of the plan of circuit is developed in the circuit planning module 12 by one of the electronic developers/users, preferably the one who selected the task in the task management module 11. The circuit plan part preferably involves the circuit diagram electronic circuit (which component is connected how with which other component) and/or the detailed circuit plan (also including the location of all conductive traces, conductive wires, via holes, electronic components in addition to their already defined connection in the electronic circuit diagram).

Where possible, the electronics developer uses circuit snippets to solve task T and to create the circuit plan part. These circuit snippets correspond to parts of the circuit plan that have already been used, verified and manufactured in other previous electronic products. This ensures a low risk of errors in the circuit excerpt and allows the circuit plan part to be developed quickly. The circuit extract is stored centrally in data storage 14 so that all electronic users/electronic developers can access it. This allows all users to use the same snippets for the same functional blocks.

In step S36, when the development of a task in step S35 is completed, the task is moved from the "in progress" category to the "done" category. This is normally done by the electronics developer/user (normally the one who developed these tasks).

In step S37, one of the electronic developers/users (normally the one who developed these tasks) selects an electronic verification group of tasks T in the "done" category and moves them into the task environment in the category " to be checked ".

The electronic verification group is then referred to, for brevity, as just the verification group. The task verification group T includes at least one task T. Preferably, the verification group includes a plurality of tasks T to make the verification process more efficient. Preferably, the verification group does not involve all T tasks in a task environment so that the verification process can already begin, while not all T tasks are completed. This already makes it possible to check certain tasks while working on other tasks and significantly speeds up the development process. Due to the difference in categories "done" and "to be verified", it is up to the electronic developer who knows the different tasks on which work is carried out and their interrelationships to define an adequate verification group or an adequate verification time of part of the tasks. Without this distinction, it would be up to the auditor to decide when to perform the audit. The auditor normally tends to postpone the audit until all tasks are done. Thus, this division into two categories of tasks made it possible to accelerate the development process with a high quality of development. When the electronic user moves the verification group task(s) to the “to be verified” category, a verification team verifies the verification group task(s).

The verification team is a sub-part of the development team. The verification team responsible for verifying electronic development is called the electronic verification team. The electronic verification team includes at least one electronic developer (different from the electronic developer who developed and completed the tasks to be verified), at least one software developer and, if there is a mechanical development object, at least one mechanical developer . The mechanical verifier may not be necessary for the verification of all tasks, but it is involved in at least some of the tasks to be verified of at least one of the electronic modules. The software verifier may not be necessary to verify all tasks, but it is involved in at least some of the tasks to be verified of at least one of the electronic modules. The users corresponding to the verifiers are called verification users, the electronic, mechanical and software users, respectively, correspond to the mechanical and software verifiers, respectively. Since the verification team responsible for verifying electronic module tasks also includes members of the mechanical and software teams, errors related to software and mechanical components can be detected at a very early stage, when these errors are not normally detected only at a late stage after the electronic product has already been manufactured and assembled. An example is that an electronic component has 10 inputs, but the software for that component can only process 8 inputs. The software checker will quickly detect this error, while an electronic checker might not notice this error.

Communication module 13 sends all data relevant to the verification process to the verification team. The verification data preferably includes the tasks in the task environment and the circuit plan related to these tasks and the electronic verification checklist. This data, in particular the circuit plan linked to these tasks, is frozen at the state/Moment when the tasks are moved from the “done” category to the “to be checked” category. This ensures that the verified circuit plans match the tasks to be verified. Otherwise, if the electronic developer continues to work on the circuit plan under development to complete other tasks in parallel with the verification process, the verifier could verify unfinished parts of the circuit plan. Therefore, it is important to create such a “frozen” circuit plan for the tasks to be verified. This verification data can be sent to the verification team, for example by simple email. The email can also be sent to all development or verification team members and one or more development/verification team members with time can complete the verification process. However, the communications module 13 may also simply provide access to the data storage 14 (to which all users have access) at a well-known or linked location so that the verifier can access all necessary verification data.

The verification process is preferably based on an electronic verification checklist. This verification checklist is standardized and is applied for each verification process in the same way. The electronic verification checklist is first prepared for the verification group to be verified by the electronic developer who developed the verification group tasks. He/she indicates for each item on the checklist whether it is applicable and whether it is correct according to the developer. When, according to the developer, all items in the checklist are correct or not applicable, he can consider the tasks ready for verification and can move the tasks from the task group to the "to be verified" category. The verifier then does the same. He/she goes through the list item by item and confirms the checklist item on the circuit plan and notes whether the list item is correct, not applicable, or not correct. If the element is incorrect, it normally also comments out what is incorrect.

Preferably, the verification process additionally includes a general check to see if there is another error in the circuit plan that is not addressed by the checklist.

Whether all items on the checklist are correct or not applicable, i.e. no errors were found for any item on the checklist (and no other errors were found in the circuit plan), the tasks of the verification group are moved to the “verified” category and these tasks are considered to have completed their development.

On the other hand, if an error has been found, the task related to the error is moved back to the “to do” task category and one of the electronic developers can work on the task again to resolve the error. These tasks must again go through the process described in steps S35, S36, S37. Certain detected errors can also trigger the generation of a new task T, for example in the case where the error is linked to a missing part in the circuit plan.

Due to the additional category for the "to be verified" category, the e-developer/user can continue working on the other unfinished tasks and move them to the "done" category, when they are completed without interfering with the verification process adding additional completed tasks in the “to be verified” category. Once all tasks in the "to be checked" category have been verified and moved out of that category (so that this category is empty), a new verification group of completed tasks can be moved from the "done" category into the “to be verified” category for a new verification process.

Step S38 must indicate that steps S35, S36, S37 are carried out for all tasks T in the task environment until all tasks T are in the “verified” category or until there are no more T tasks left in the “to do”, “in progress”, “done”, “to check” categories. This process for different tasks can be done sequentially and/or in parallel, with an individual task, with groups of tasks, etc. With each verified task T, a new part of the circuit plan of the electronic module is completed. When all T tasks are verified, the circuit plan of the electronic module has been fully developed and the circuit plan (optionally converted to production files) is sent to manufacturing in step S7.

As already mentioned, this task management process is repeated for each electronic module and/or each task environment. This is shown in Figure 4 with step S39. When all the electronic modules have been developed, the circuit plan of the electronic device is obtained.

In a preferred embodiment, only the electronic developer/user who developed the respective task can move the task in step S35 from the "to do" category to the "in progress" category, to step S36 from the category “in progress” in the “done” category and/or at step S37 of the “done” category in the “to be verified” category.

In a preferred embodiment, only the verifier/verifier user who verifies the tasks can move tasks in step S37 from the "to be verified" category to the "verified" category or to the "to do" category, at step S36 of the “in progress” category in the “done” category and/or step S37 of the “done” category in the “to be verified” category.

Figure 5 now shows the S3 mechanical development process in more detail. The mechanical process ends with the design plan of the mechanical parts of the electronic device. The design plan is preferably a 3D CAD plan.

In step S21 the mechanical development object is divided into at least one mechanical module to be developed, preferably into at least two mechanical modules. Each mechanical module preferably corresponds to a physical unit of mechanical components which can be easily manufactured independently of the other mechanical modules. This step is preferably carried out by a developer from the mechanical development team, preferably by at least one lead developer from the mechanical development team.

The following steps are described for a mechanical module. These steps end with a design plan for each mechanical module which together provide/constitute the design plan for the mechanical parts of the electronic device. It is obvious that the description is also valid for more than one, preferably for all mechanical modules. Since the S3 mechanical development process is analogous to the S4 electronic development process described in Figure 4, the S3 mechanical development process is only briefly described without details. It is clear that the above disclosure of Figure 4 is also valid by replacing electronic with mechanical (and possibly vice versa) and replacing the circuit planning module 12 with the mechanical planning module 16.

In step S22, a task environment is generated in the task management module 11 for the mechanical module. This is preferably done by one of the mechanical users. However, an electronic or software user could also do this.

In step S23, the tasks T for finalizing the mechanical module are defined and generated in the task environment of the mechanical module. The generated tasks T are placed in the “to do” task category. As explained above for the electronic development process in step S34, if there is an additional task category for scheduled tasks, placing the task in the "to do" category may also mean placing the task in the additional task category and moving it, when it becomes relevant, to the “to do” task category.

At step S24, one (or more) of the mechanical developers starts working on one (or more) task(s) T of the tasks in the “to do” category. When he/she starts working on task T, task T is moved from the “to do” task category to the “in progress” category. Working on task T involves creating a part of the mechanical module design plan that is related to task T. This part of the design plan is carried out in the mechanical planning module 16. The part of the design plan preferably involves the CAD plan of the mechanical parts related to the task.

In step S25, when the development of a task in step S24 is completed, the task is moved from the "in progress" category to the "done" category. This is normally done by the mechanical developer/user (normally the one who developed these tasks).

In step S26, one of the mechanical developers/users (normally the one who developed these tasks) selects a task verification group T from the "done" category and moves them into the task environment in the "done" category. to be checked ". The mechanical verification group of tasks T includes at least one task T. Preferably, the mechanical verification group includes a plurality of tasks T to make the verification process more efficient. Preferably, the mechanical verification group does not involve all T tasks in a task environment so that the verification process can already begin, while not all T tasks are completed. This already makes it possible to check certain tasks while working on other tasks and significantly speeds up the development process. Due to the difference in categories "done" and "to be verified", it is up to the mechanical developer who knows the different tasks on which work is being done and their interrelationships to define an adequate verification group or an adequate verification time of part of the tasks. This can obviously also be the case when all tasks in the task environment are in the "done" category. Without this distinction, it would be up to the auditor to decide when to perform the audit. The auditor normally tends to postpone the audit until all tasks are done. Thus, this division into two categories of tasks made it possible to accelerate the development process with a high quality of development. When the mechanical user moves the verification group task(s) to the “to be verified” category, the mechanical verification team verifies the verification group task(s).

The mechanical verification team of the verification team is responsible for verifying mechanical development. The mechanical verification team includes at least one mechanical developer (different from the mechanical developer who developed and completed the tasks to be verified), at least one software developer and/or at least one electronic developer.

The communication module 13 sends all data relevant for the verification process to the verification team, in particular the mechanical verification team. The verification data preferably includes the tasks in the task environment and the design plan related to those tasks and the mechanical verification checklist. This verification data, in particular the design plan linked to these tasks, is frozen at the state/moment when the tasks are moved from the “done” category to the “to be verified” category. This ensures that the verified design plan actually corresponds to the tasks to be verified. Otherwise, if the mechanical developer continues to work on the design plan under development to complete other tasks in parallel with the verification process, the verifier could verify unfinished portions of the design plan. Therefore, it is important to create such a “fixed” design plan for the tasks to be verified. This verification data can be sent to the (mechanical) verification team, for example by a simple email. The email can also be sent to all members of the development or review team. One or more development/verification team member(s) with time can complete the verification process. However, the communications module 13 may also simply provide access to the data storage 14 (to which all users have access) at a well-known or linked location so that the verifier can access all necessary verification data.

The verification process is preferably based on a mechanical verification checklist. This mechanical verification checklist is standardized and is applied for each verification process in the same manner. The mechanical verification checklist is first prepared for the verification group to be verified by the electronic developer who developed the verification group tasks. He/she indicates for each item on the checklist whether it is applicable and whether it is correct according to the developer. When, according to the developer, all items in the checklist are correct or not applicable, he can consider the tasks ready for verification and can move the tasks from the task group to the "to be verified" category. The verifier then does the same. He/she goes through the list item by item and confirms the checklist item on the design plan and notes whether the list item is correct, not applicable, or not correct. If the element is incorrect, it normally also comments out what is incorrect.

Preferably, the verification process additionally includes a general check to see if there is another error in the design plan that is not addressed by the checklist.

Whether all items on the checklist are correct or not applicable, i.e. no errors were found for any item on the checklist (and no other errors were found in the design plan), the verification group tasks are moved to the “verified” category and these tasks are considered to have completed their development.

On the other hand, if an error was found, the task related to the error is moved back to the "to do" task category and one of the mechanical developers can work on the task again to resolve the error. These tasks must again go through the process described in steps S24, S25, S26. Certain detected errors can also trigger the generation of a new task T, for example in the case where the error is linked to a missing part in the circuit plan.

Step S27 must indicate that steps S24, S25, S26 are carried out for all tasks T in the task environment until all tasks T are in the “verified” category or until there are no more T tasks left in the “to do”, “in progress”, “done”, “to check” categories. This process for different tasks can be done sequentially and/or in parallel, with an individual task, with groups of tasks, etc. With each verified task T, a new part of the mechanical module design plan is completed. When all T tasks are completed and verified, the mechanical module design plan has been fully developed and the design plan (optionally converted to production files) is sent to manufacturing in step S6.

As already mentioned, this task management process is repeated for each mechanical module and/or each task environment. This is shown in Figure 5 with step S28. When all the mechanical modules have been developed, the design plan of all the mechanical parts of the electronic device is obtained.

Another important aspect of invention is project closure. Once the electronic product is developed, manufactured and formed/assembled, a number of important steps are carried out to optimize the development process for the future. So, at this stage, the electronic product is tested, and it is confirmed that the electronic device no longer has any (at least obvious) errors.

At this point, the developed circuit plan is checked to see if there are any parts of the circuit plan that could be reused for other future developments. For example, the first time a 5V power supply circuit was developed, the circuit plan of the 5V power supply circuit is stored as an extract in data storage 14. Thus, the next Once a developer needs a 5V power supply, they can simply use the pre-stored snippet created by the previous development. Because the snippet is available to all users, all users tend to use the same snippets for the same functions. This increases the robustness of the circuit because the same circuit part is tested in many different devices, making it very robust against errors.

During the development and validation process of steps S1 to S10, all errors made are tracked and studied at project closure. In particular, errors that were not identified by the checklist will be tracked and investigated in more detail. Such errors may be detected in the verification process by the verification team (without the help of the checklist) or after manufacturing during validation of the electronic circuit board or during testing of the completed electronic device . If this error has occurred in several projects or it is very important that it does not happen again, the checklist is suitable to identify this error in the future in the verification process. This can be done by adding a checklist item.

It will be understood that the present invention is not limited to the embodiments described and that variations may be applied without departing from the scope of the claims.

Claims (9)

1. Method for manufacturing an electronic device using a computer system (10) and a development team, in which the development team comprises an electronic development team and a software development team, in which the development team comprises a plurality of developers, in which the electronic development team comprises at least two electronic developers, in which the software development team comprises at least one software developer, in which the computer system (10 ) is accessible by a plurality of users and comprises a task management module (11), a circuit planning module (12), a communication module (13), a data storage (14), in which the plurality of users correspond to user access to the computer system (10) for the plurality of developers of the development team, wherein the plurality of users include at least two electronic users corresponding to the at least two electronic developers and the at least one software user corresponding to at least one software developer, in which the task management module (11) is configured to generate different task environments, in which the task management module (11) is configured to generate in each environment of different tasks (T) and to move the generated tasks between different task categories which contain the task category "to do", the task category "in progress", the task category "done" and the task category “to be verified” and the task category “verified”, in which the circuit planning module (12) is configured to generate a circuit plan of the electronic device, in which the communication module (13) is configured to allow the communication between users, in which the data storage (14) is configured to store data accessible by all users, wherein the method comprises the following steps of: e definition of specifications of the electronic device (S1); e definition (S2), based on the specifications, of an electronic development object to be developed by the electronic development team and of a software development object to be developed by the software development team, e development of a circuit plan of the electronic device on the basis of the electronic development objective (S4) using the computer system (10), e developing software of the electronic device on the basis of the software development objective (S5 ) using the computer system (10), manufacturing (S7) electronic modules based on the final circuit plan obtained resulting in at least one circuit board manufactured; e validation (S9) of the at least one circuit card manufactured; e forming the electronic device by assembling (S10) the at least one circuit board, and programming the electronic components of the at least one circuit board with the developed software, and the mechanical parts; e wherein the development of the circuit plan of the electronic device (S4) comprises the following steps of: e definition of electronic blocks (S31) which solve the electronic development object resulting in an electronic block diagram, in which each electronic block contains the selected main electronic component necessary for the respective electronic block; e division of the electronic functional diagram (S32) into different electronic modules; e development of circuit plans for the electronic modules, wherein the circuit plans of the electronic modules together constitute the circuit plan of the electronic device, wherein the development of each circuit plan of the electronic modules comprises the following steps of: e generation of a task environment for the electronic module in the task management module (11), e generation in the task environment of a plurality of tasks (T) in the “to do” task category, wherein the plurality of tasks (T) define the development tasks for developing the circuit plan of the electronic module , e one of the electronic users works on one or more generated tasks (T) and the respective task(s) (T) are moved, when the electronic user starts working on it, to the "in progress" task category in the task environment, in which working on the one or more tasks (T) involves one of the electronic developers designing, in the circuit planning module (12), a part of a circuit plan of the module electronics linked to the one or more tasks (T), e for each task (T) that is completed, the task (T) is moved to the "done" task category, the completed task (T) leads to the part of the circuit plan of the electronic module related to the task (T ) finished, e when one or more tasks (T) are completed and moved to the "done" task category, an electronic verification group of at least one task (T) to be verified is selected by moving the selected electronic verification group into the category of tasks “to be verified”, e at least one task of the electronic verification group in the “to be verified” task category is verified by an electronic verification team, in which the part of the circuit plan of the electronic module corresponding to the at least one task of the electronic verification group is sent via the communication module (13) to the electronic verification team for verification, in which the team of electronic verification comprises at least one electronic user different from the electronic user who worked and completed the electronic verification group of at least one task (T) to be verified, if the electronic verification team approves the corresponding part of the circuit plan to the selected task to be verified, the selected task is moved to the "verified" task category in the task environment, if the electronic verification team finds an error in the part of the circuit plan corresponding to the selected task, the selected task is returned to the “to do” task category with an explanation of the at least one error, in which the verification of the tasks of the electronic verification group is carried out on the basis of an electronic verification checklist, in which each item of the electronic verification checklist identifies what needs to be checked, whether the head of the e-verification team is an electronic developer or a software developer, and the result of the verification process of this item must be entered by the e-verification team, e repeat this process for the generated task environment until all tasks are in the “verified” task category and the final circuit plan of the electronic module is obtained by the combination of the parts of the circuit plan provided by all verified tasks, e in which for at least one electronic verification group of at least one of the electronic modules, the at least one task of the at least one electronic verification group comprises at least two tasks to be verified, in which for at least one electronic verification group of at least one of the electronic modules, the electronic verification team comprises one of the at least one software developer; e in which if for the part of a circuit plan related to a task in the category "in progress" exists a fragment, one of the electronic developers working on this task designs, in the circuit planning module (12) , the part of a circuit plan of the electronic module linked to the one or more tasks (T) using the fragment stored on the data storage (14), in which the fragment represents pre-stored circuit models to be used in the circuit planning module (12) usable by all users (14); e in which the circuit plan of the electronic device is controlled, after the formation of the electronic product and after having validated the at least one circuit board, if the circuit plan contains parts of the circuit plan which could be reused for the development of future electronic devices, if so, a fragment of this part of the circuit plan is created and stored in the data storage (14) accessible to all users; e wherein errors made during the development of the circuit plan of the electronic device are tracked, wherein the tracked errors are used to update the electronic verification checklist. 2. Method according to one of the preceding claims, in which the development team comprises a mechanical development team, in which the mechanical development team comprises at least one mechanical developer, in which the plurality of users comprises at least a mechanical user corresponding to the at least one mechanical developer, in which the method comprises the steps of: e definition (S2), on the basis of the specifications, of a mechanical development object to be developed by the mechanical development team ; e development of the mechanical design plan of the electronic device based on the mechanical development objective (S3) using the computer system (10), e manufacturing of mechanical parts of the electronic device based on the developed mechanical design plan; e forming the electronic device by assembling (S10) the at least one manufactured circuit board and the manufactured mechanical parts. 3. Method according to the preceding claim, in which the manufacture of at least one mechanical part involves 3D printing. 4. Method according to claim 2 or 3, in which for at least one electronic verification group of at least one of the electronic modules, the electronic verification team comprises one of the at least one mechanical developer. 5. Method according to one of claims 2 to 4, in which the computer system (10) comprises a mechanical design module (16), in which the development of the mechanical design plan of the electronic device comprises the definition of at least a mechanical module and following steps for each mechanical module: e generation of a task environment for the mechanical module in the task management module (11), e generation, in the task environment, of a plurality of tasks (T) in the "to do" task category, wherein the plurality of tasks (T) define development tasks for developing a design plan for the mechanical module, e one of the mechanical users works on one or more generated tasks (T), and the respective task(s) (T) are moved, when the mechanical user starts working on it, to the "in progress" task category in the task environment, in which work on the one or more tasks (T) involves one of the mechanical developers designing, in the circuit planning module (12), part of the design plan of the mechanical module linked to the task(s) (T), e for each completed task (T), the task (T) is moved to the “done” task category, the completed task (T) leads to the design plan part of the mechanical module linked to the completed task (T), e when one or more tasks (T) are completed and moved to the “done” task category, a verification group of at least one task (T) to be verified is selected by moving the selected verification group to the category tasks “to be checked”, e the at least one task of the verification group in the task category “to be verified” is verified by a mechanical verification team, in which the part of the design plan of the mechanical module corresponding to the at least one task of the group mechanical verification is sent via the communication module (13) to the mechanical verification team for verification, wherein the mechanical verification team includes at least one mechanical user different from the mechanical user who worked and completed the group of mechanical verification of at least one task to be verified, if the mechanical verification team approves the part of the design plan corresponding to the selected task to be verified, the selected task is moved to the task category "verified" in the task environment, if the verification team finds an error in the part of the design plan corresponding to the selected task, the selected task is returned to the "to be done" task category with an explanation of at least one error, e repeat this process for the generated task environment until all tasks are in the “verified” task category and the final mechanical module design plan is obtained by combining the parts of the design plan provided by all the verified tasks, e in which the at least one design plan of at least one mechanical module constitutes the mechanical design plan of the mechanical parts of the electronic device, e in which for at least one mechanical verification group of at least one of at least one mechanical module, the at least one task of the at least one mechanical verification group comprises at least two tasks to be verified. 6. Method according to claim 5, in which for at least one mechanical verification group of at least one of the mechanical modules, the mechanical verification team comprises one of the at least one electronic developer, in which for at least one mechanical verification group of at least one of the mechanical modules, the mechanical verification team includes one of the at least one software developer. 7. Method according to claim 6, wherein the verification of the tasks of the mechanical verification group is carried out based on a mechanical verification checklist, wherein each item of the mechanical verification checklist identifies what must be verified, whether the person responsible for this element of the mechanical verification team is a mechanical developer, the project manager, an electronic developer or a software developer, and the result of the verification process of this element must be entered by the mechanical inspection team. 8. Method according to claim 7, in which the at least one mechanical module comprises at least two mechanical modules. 9. The method of claim 8, wherein errors made during the development of the design plan of the mechanical parts of the electronic device are tracked, wherein the tracked errors are used to update the mechanical verification checklist.