What is a typical day like for a Solar Energy Systems Engineer?
#engineering #solar energy #Renewable Resources and Energy
3 answers
naveen’s Answer
They sphere of knowledge includes Mechanical, Electrical and Civil Engineering.
They research, design, and develop new products, or they may work in testing, production, or maintenance.
They may collect and manage data to help design solar systems.
The engineer typically begins with a client consultation, site assessment, and financial assessment, which help him
or her understand the project's context.
The Solar Engineer is responsible for engineering, design (using AutoCAD), and delivery of grid connected solar photovoltaic systems (including rooftop, carport and ground mounted arrays) on time and on budget. The Solar Engineer will manage proposals and the bid/award process for obtaining these services, and will provide project management and design consultation for all projects. Design to include; scope of work, complete bill of materials, specifications, bid drawings and project schedule.
Safety Precautions while handling Solar panels.
• Use proper protective gear –Glasses, Gloves, etc. to reduce the risk of electric shock.
• Do not wear metallic jewelry while working with any electrical circuits.
• Hold solar panels with two hands while transporting. Do not hold by the junction box or wires.
•Keep the solar panel covered until after you’ve mounted and made all electrical connections.
•Be careful not to touch any live positive wire with a live negative wire.
Fundamental steps followed in installation process.
Step 1 –Plan your Installation.
Step 2 –Route the Wire.
Step 3 –Mount & Wire Solar Charge Controller.
Step 5 –Connect the Battery Wires.
G. Mark’s Answer
Be aware that a Systems Engineer is a bit different from other engineers. A Systems Engineer is expected to understand the entire system from end-to-end. The SE may be involved in implementation, but not necessarily. The SE would be involved in the definition of the problem to be solved, the various solutions, writing requirements, and defining verification criteria for the finished project. So a typical day would be -- assuming the project has just started -- research. Research the situation and, nowadays most likely, contacting the users of the solution. This means not only knowing your product, but understanding the needs of the people you will be providing this solution to. This involves a lot of communication with everyone involved -- customers, clients, engineers, etc..
Once a set of solution proposals have been put together, the SE will be contacting various stakeholders -- all the people with some vested interest in the project and its outcome, such as customers, managers, testers, resource and material providers, engineers, designers and so on. The idea is to not only verify that the project is moving along as per expectations, that roadblocks are being dealt with, that engineers and other implementers are satisfied with their requirements and expectations.
In my case, I generally was interested in how the implementations were being done. SE s typically write requirements and are "agnostic" as to how they're implemented. Personally, I usually had a solution and a fair idea of how it would be implemented. I was even often right. But having that vision made it much easier to convince engineers that my requirement was doable. And it bought me credibility with the customer, who sometimes even wanted to know how we were doing to make this crazy idea work.
Now, I'd like to say that after deployment, the SE spent the day getting congratulated and thanked for the tremendous effort, but in fact, we were all exhausted and then spent the time looking for the next cool project.
Eric’s Answer
Eric recommends the following next steps: