One problem that arises in our PE is that in some cases infinite design loops might occur due to some conflict between the constraints in different subsystems. For example, assume that the design system changed the link length to some value, say from 3.0 to 2.0 inches, to satisfy some performance requirements. This change would change the link mass as well, say from 1.5 to 1.0 lbs. According to the mass change the gear ratio has to change or the motor should be replaced, but if there is a constraint on the sprocket radius such that it can be increased, and there is no other motor with lower rpm, then the mass should be changed again to be 1.5 lbs, which requires the length to be 3.0 inches again. If we let the system continue, the design system will change the link length again and the loop will continue.
There are several solutions to this problem. One way is to make the user part of this loop so that some of the performance requirements can be changed, or a solution can be selected even if it does not meet some required criteria. This requires the user to be a skilled person who has the knowledge and experience in the design process, and also to have the authority to change and select solutions irrespective of the original requirements. Another solution is to put some limitations on the subsystem regarding its ability to change some of the design parameters. These limitations should guarantee infinite loop prevention in the system. A third solution is to put all the constraints in the CI. This allows the CI to check the solution and detect any violation to any of the constraints; then it may ask the user to decide on another solution or to change some of the performance requirements and run the design subsystem again. The last solution has the user in the loop as well, but incorporating all the constraints in the CI reduces the interprocess communication and speeds up the checking process. This last solution was chosen in our design.