대규모 임베디드 프로젝트를 어떻게 구성합니까? [닫은]

배경 :

주니어 R & D 전자 엔지니어 ( 회사에서 유일한 EE )-하드웨어 및 코딩은 문제가되지 않습니다. 가장 큰 문제는 프로젝트의 개요와 시작 위치를 얻는 것입니다.

지금까지 작은 소프트웨어 프로젝트 (500 줄 이하의 코드) 만 만들었지 만 기능에 대한 개요를 잃지 않거나 기능이 부족하지 않으면 서 더 큰 프로젝트를 수행 할 수는 없습니다.

대형 임베디드 소프트웨어 시스템을 구성하는 데 가장 적합한 구조 / 어떻게 도구를 사용합니까?

내가 현재하고있는 일 :

나는 보통 프로젝트의 기능을 스케치함으로써 시작합니다. 일대 다 계층화 된 플로우 차트 또는 관련 다이어그램 (블록 다이어그램 등) 일 수 있으며 구성 요소 / 칩에 대한 일부 연구를 수행합니다. 그런 다음 데이터 시트 / 인터넷을 참조하면서 한 번에 하나의 기능을 코딩하고 더미 데이터 또는 유사한 테스트로 테스트하면서 코딩 (빠른 추측)에 뛰어 들었습니다. MEM 칩에 데이터를 쓰는 것일 수 있으며, 작동하면 메인 칩과 MEM 칩 사이의 SPI 드라이버 일 수 있습니다.

내가 찾고있는 답변 :

정말요 나는 현명한 것을 정리할 것이다. 책, 기사, 개인적인 경험, 추천 등이 될 수 있습니다.

저는 노인들이 어떻게이 문제를 해결하는지 알고 싶습니다.

편집하다

우선, 수년간의 경험을 공유해 주셔서 감사합니다! 모든 답변에 감사드립니다. 이것에서 나의 테이크는;

• 명확하고 정확한 사양 문서를 작성하십시오.
• 소프트웨어 디자인 문서를 작성하십시오. (이제 추가 할 것) 디자인 문서 템플릿
• 중복되는 것처럼 보일 수있는 모듈을 생각해보십시오. (더 집중해야 할 것)
• 헤더 / 소스 파일을 구성하기위한 코딩 표준을 따르십시오. (결코이했다) 바 그룹 C 표준을
• 먼저 저수준 구현을 만드는 데 중점을 둡니다. (통신 등)
• 가능한 한 현명한 디자인 패턴을 구현하십시오. 디자인 패턴
• 개정 관리를 위해 무언가를 설정하십시오 (Github 등-많이 사용하지 마십시오)
• 지속적인 통합 / 지속적인 배포 연구 (구체적인 새로운 문제) CI 및 CD 기본 사항

프로젝트의 구조화에 대한 세부 등급에 영향을 미치는 몇 가지 측면이 있습니다. 나에게 주요 요인 중 하나는 내가 유일한 코딩인지 (당신이 유일한 EE라고 쓸 때 당신에게 해당되는 것처럼 보이는지) 또는 다른 관련자가 있는지 여부입니다. 그렇다면 "큰"이 실제로 무엇을 의미하는지에 대한 의문이 있습니다. 일반적으로 디자인 프로세스를 다음 단계로 나눕니다.

요구 사항 정의 많은 계획을 수행하기 위해 적절한 소프트웨어 스펙을 확보 한 경우 이미 완료되었습니다. 모호한 요구 사항 만 충족하는 경우 가장 먼저해야 할 일은 고객이 실제로 원하는 것을 정렬하는 것입니다 (때로는 처음에 알지 못하는 경우도 있음). 코딩으로 바로 뛰어 들고 싶은 유혹이 있지만, 처음에는 분명하지 않았고 개발 도중 어딘가에 코드에 쉽게 넣을 수없는 중요한 기능을 놓칠 위험이 있습니다.

시스템 경계 및 유지 보수성 임베디드 시스템에는 종종 일부 시스템 인터페이스가 있으며 일부는 외부 (운영자)와 내부에 있습니다. 이를 잘 정의하고 종속성을 가능한 한 낮게 유지하려고하면 지속적인 엔지니어링 및 유지 관리가 간단 해집니다. 또한 필요한 경우 주석 / 문서 코드를 사용하면 다른 사람과 함께 작업 해야하는 사람을 절대 알 수 없습니다. 함수는 실제로 기능이 무엇인지 알기 전에 수십 개의 코드 레이어를 파지 않아도 기뻐할 것입니다.

검증 가능한 작업 정의 특히 다른 개발자가 동일한 코드 기반으로 작업하는 경우 명확한 작업 (기능)과 필요한 인터페이스를 정의하는 것은 불가피합니다. 가능할 때마다 개별 기능을 다른 기능과 독립적으로 테스트 / 검증해야합니다. 테스트 케이스를 정의 할 수 있도록 인터페이스를 잘 정의해야합니다.

진전을 좋아 하는 사람들에게 하나의 기능 이 있습니다. 따라서 다양한 작업이있는 경우 대개 가장 큰 발전을 약속하는 모든 작업을 수행합니다. 나는 보통 다음 작업을 시작하기 전에 작업을 끝내고 검증되고 테스트 된 상태로 만듭니다. 이를 통해 다른 사람들이 코드를 테스트 할 수 있으며 무언가를 잊어 버리지 않습니다.

개정 관리 프로젝트가 진행되는 동안 때때로 구 버전이 필요할 수도 있습니다. 일부 새로운 릴리스에 도입 된 버그를 식별하거나 3 년 전에 출하 한 것과 정확히 동일한 방식으로 작동하는 장치를 구축 할 수도 있습니다. 코드에 명확한 빌드 개정 및 태그가 있는지 확인하십시오. Git은 확실히 당신의 친구입니다.

Humpawumpa는 큰 답변을 썼습니다 ! 나는 그의 요점 중 일부를 보완하고 싶지만 이것이 너무 길어서 주석이되기 때문에 별도의 답변을 쓸 것입니다.

한 번은 OP의 입장에있었습니다. 유일한 EE뿐만 아니라 소규모 회사에서 MCU 개발을 한 유일한 EE입니다.

당신이 유일한 개발자 인 경우에도 모듈성 의 중요성을 충분히 강조 할 수는 없습니다 . 프로젝트가 성장함에 따라 제정신을 유지할 수있는 유일한 방법입니다. 각각 하나의 기능적 개념 만 처리하는 모듈을 작성하고 외부 인터페이스를 최대한 최소화해야합니다. 높은 수준의 모듈은 기능 요구 사항에 해당하는 반면 낮은 수준의 모듈은 하드웨어 리소스 (예 : 장치 드라이버)와 밀접한 관련이 있습니다.

다양한 데이터가 정보를 공유하는 방법을 정확하게 보여주는 자세한 데이터 흐름도 ^1을 유지하는 데 많은 시간을 보냈습니다 . 일부 기능은 실시간 성능 측면에서 요구 사항이 매우 다릅니다. 정보 공유가 어떻게 영향을 미치는지 알고 있어야합니다. 다이어그램에는 여러 인터럽트 구동 도메인과 비 인터럽트 코드를 구분하는 경계가 그려져 있습니다.

¹ 제어 흐름에 중점을 둔 흐름도와 매우 다릅니다 .

대규모 프로젝트의 경우, 모든 일을 스스로하려고해도 여러 개발자가 참여한 것처럼 계획합니다.

이유는 간단합니다.

1 복잡성. 대규모 프로젝트에는 항상 복잡성이 수반됩니다. 여러 팀이 참여한 것처럼 프로젝트를 계획했다는 것은 복잡성이 고려 되고 문서화 되었음을 의미합니다 . 큰 프로젝트가 문제를 겪는 것을 본 횟수는 많으며 일반적으로 '크랙을 통해 무언가가 because 겨서'발생합니다. 단순히 박스 크기가 아닌 기계적 조립도 고려해야한다는 점을 잊지 마십시오. 방열판이 필요합니까? 상자가 안전을 위해 접지되어야합니까? 이 범주에만 많은 질문이 있습니다.

2 요구 사항. 여러 사람이 관련되어 있다고 가정하면 최상위 요구 사항 (필요하지 않은 복잡성과 비용을 초래할 수 있으므로 자주 도전) 은 다양하고 더 작고 달성 가능한 다양한 작업 (대규모 조직의 다른 팀에 제공 될 수 있음)으로 분류되어야합니다. ) 하나의 얼룩 만 보는 것이 아니라

3 파티셔닝. 파티셔닝에는 두 가지 주요 유형이 있습니다. 하드웨어 기능 및 하드웨어 / 소프트웨어. 첫 번째 유형은 어떤 별도 (그러나 통신) 기능 블록이 있어야하는지 결정하는 것입니다. 두 번째는 더 단순한 (때로는) 하드웨어와 소프트웨어의 절충이지만 더 많은 것을 소프트웨어로 옮기는 것이 반드시 하드웨어 문제를 해결하지는 않는다는 점을 명심하십시오. 소프트웨어로 더 많이 옮기면 실제로는 상황에 따라 하드웨어 복잡성이 크게 증가 할 수 있습니다 (처리 능력, 복잡한 인터페이스 등).

4 인터페이스. 파티셔닝 프로세스는 내부 인터페이스를 정의하는 데 도움이됩니다. 외부 인터페이스는 일반적으로 전체 요구 사항의 일부입니다 (항상 그런 것은 아님). 있습니다 많은 복잡한 통신 프로토콜 또는 단순히 좋은 / 나쁜 신호가 될 수있다 - 운영 공동으로 시스템의 다른 부분에 대한 방법.

5 검증. 이것은 저수준 테스트 (하드웨어 및 드라이버)와 시스템 수준의 혼합입니다. 잘 정의 된 블록으로 프로젝트를 수행하면 강력한 검증이 가능합니다 (분석 또는 실제 테스트에 의한 것일 수 있으며 일반적으로이 둘을 혼합 한 것입니다. 설계에 대한 업데이트는 유사성 인수를 사용할 수 있음).

6 표준. 나는 더 큰 팀인 것처럼 코딩 및 드로잉 표준을 사용합니다. Barr 그룹의 코딩 표준 은 너무 번거롭지 않지만 코드에 많은 종류의 버그가있는 것을 막기 때문에 사용합니다. PCB 출력 문서의 경우 IPC-D-326 (IPC-D-325를 호출 함)을 따라 의도를 PCB 제작자와 어셈블러에 전달하는 입증 된 방법입니다. 이것은 이상하게 보일지 모르지만 여러 표준을 준수하는 규율이 있다는 것은 품질이 일정하다는 것을 의미합니다.

7 버전 관리. 프로젝트의 모든 부분 (시스템, 하드웨어, 소프트웨어, 기계, 테스트 요구 사항-모든 것)에 대해 개정 제어를 사용 합니다. 내가 사용하는 CAD 도구는 모든 소프트웨어 및 FPGA 빌드 도구와 같은 버전 관리를 지원합니다.

나는 많은 임베디드 프로젝트 (여기서 경험 많은 사람들과 마찬가지로)에서 일했으며 팀 규모는 1 (나 자신)에서 수십 (또는 특정 프로젝트에서 수백)에 이르기까지 여러 분야에 걸쳐 있으며 때로는 지리적으로 멀리 떨어져 있습니다. 사이트. 작동하는 것으로 알려진 동일한 아카이빙 방식을 사용하면 특정 작업을 상대적으로 격리하여 완료하여 더 큰 프로젝트의 독립형 부분으로 철저히 테스트 할 수 있습니다. 또한 필요한 경우 때때로 일부를 대체 할 수 있음을 의미합니다.

이러한 모든 작업을 수행하면 약간의 선행 시간이 필요하지만 궁극적으로는 복잡한 임베디드 시스템을위한 더 빠른 경로입니다.

다른 답변은 많은 유용한 팁을 제공합니다. 임베디드 개발 경력에서 가장 중요한 두 가지는 다음과 같습니다.

1. 가능한 많은 코드를 별도의 잘 정의 된 모듈로 만드십시오.
2. PC에서 모듈을 자동으로 테스트 할 수 있도록합니다.

이것이 임베디드 시스템에서 "연속 통합"스타일 개발을 수행하는 데 필요한 것입니다. 자동 테스트를 위해 하드웨어와 너무 밀접하게 연결된 코드가 항상 있지만 최소화하려고합니다. 실제 하드웨어에서 시뮬레이트 된 데이터 또는 데이터 캡처를 사용하여 테스트 시스템에 제공함으로써 상당히 멀리 갈 수 있습니다.

기존 답변에 추가하려면 ...

나는 항상 아래에서 위로 시작합니다. 하드웨어 설계에서 I / O가 무엇인지 알 수 있습니다. I / O를 캡슐화하는 드라이버 모듈을 빌드하여 시작하십시오. 따라서 높은 수준의 코드는 낮은 수준의 내용에 대해 너무 많이 알 필요가 없습니다.

저수준 인터페이스를 구축 할 때는 물론 테스트 장치가 필요합니다. 처음부터 PC에 연결하도록 이것을 설계하면 (아마도 RS-232 포트, 아마도 USB, 아마도 telnet over Ethernet) 응용 프로그램을 빌드 할 때이 테스트 하니스 인터페이스를 유지할 수 있습니다. 응용 프로그램이 구체화됨에 따라 테스트 하니스 후크를 계속 추가 할 수 있으며 코드를 회귀 테스트 할 수 있습니다.

나는 네 가지 질문으로 생각하는 경향이 있습니다. 처음 2 개는 시스템 프로젝트의 시작에 속하고 2 개는 끝을 향합니다.

1. 그들은 실제로 시스템을 원합니까? 시스템은 고객이 받아 들일 수있는 시간과 비용 규모로 고객 문제를 해결합니까? 일반적인 문제는 고객이 사용하지 않는 시스템을 구축하는 것입니다.

2. 실제로 그 시스템을 구축 할 수 있습니까? 필요한 성능, 정밀성, 전력 사용량을 제공 할 수 있습니까?

초기 프로토 타입을 만드는 것이이 두 가지 첫 번째 질문에 대답하는 좋은 방법입니다. 위험 완화는 초기 단계에서 매우 중요합니다.

다음 두 가지 질문은 프로젝트의 후반부에보다 집중적으로 나타납니다.

3. 우리는 실제로 끝났습니까? 설계, 코딩, 테스트, 제공

4. 그들은 실제로 시스템을 사용합니까?