main.tex

\documentclass[a4paper,nobib,justified]{tufte-book}

\usepackage{relsize}

\usepackage[utf8]{inputenc}
\input{preamble.tex}

\addbibresource{bibliography.bib}

% Greek
\usepackage[greek,english]{babel}
\usepackage{alphabeta}
\let\textlozenge\undefined
\usepackage{gfsartemisia-euler}
\NewDocumentCommand{\g}{+m}{\foreignlanguage{greek}{#1}}
\NewDocumentCommand{\e}{+m}{\foreignlanguage{english}{#1}}
%\usepackage{hyphenation-greek}
%\input{hyphenation-el.tex}
\DefineBibliographyStrings{english}{%
	page             = {σ\adddot},
	pages            = {σσ\adddot},
}
\DefineBibliographyExtras{USenglish}{%
	% d-m-y format for long dates
	\protected\def\mkbibdatelong#1#2#3{%
		\iffieldundef{#3}
		{}
		{\stripzeros{\thefield{#3}}%
			\iffieldundef{#2}{}{\nobreakspace}}%
		\iffieldundef{#2}
		{}
		{\mkbibmonth{\thefield{#2}}%
			\iffieldundef{#1}{}{\space}}%
		\iffieldbibstring{#1}{\bibstring{\thefield{#1}}}{\stripzeros{\thefield{#1}}}}%
	% d-m-y format for short dates
	\protected\def\mkbibdateshort#1#2#3{%
		\iffieldundef{#3}
		{}
		{\mkdatezeros{\thefield{#3}}%
			\iffieldundef{#2}{}{/}}%
		\iffieldundef{#2}
		{}
		{\mkdatezeros{\thefield{#2}}%
			\iffieldundef{#1}{}{/}}%
		\iffieldbibstring{#1}{\bibstring{\thefield{#1}}}{\mkdatezeros{\thefield{#1}}}}%
}

% Override tufte command for headers to remove greek accents
\makeatletter
\ExplSyntaxOn
\cs_new_protected:Npn \removeaccent #1 {
	\tl_set:Nn \replace_str {#1}
	\def\acctonos{}
	\let\accdialytikatonos\accdialytika
	\tl_replace_all:Nnn \replace_str { ά } { α }
	\tl_replace_all:Nnn \replace_str { έ } { ε }
	\tl_replace_all:Nnn \replace_str { ή } { η }
	\tl_replace_all:Nnn \replace_str { ί } { ι }
	\tl_replace_all:Nnn \replace_str { ό } { ο }
	\tl_replace_all:Nnn \replace_str { ύ } { υ }
	\tl_replace_all:Nnn \replace_str { ώ } { ω }
	\tl_replace_all:Nnn \replace_str { ϊ } { ϊ }
	\tl_replace_all:Nnn \replace_str { ϋ } { ϋ }
	\tl_replace_all:Nnn \replace_str { ΐ } { Ϊ }
	\tl_replace_all:Nnn \replace_str { ΰ } { Ϋ }
	\tl_replace_all:Nnn \replace_str { Ά } { α }
	\tl_replace_all:Nnn \replace_str { Έ } { Ε }
	\tl_replace_all:Nnn \replace_str { Ή } { Η }
	\tl_replace_all:Nnn \replace_str { Ί } { Ι }
	\tl_replace_all:Nnn \replace_str { Ό } { Ο }
	\tl_replace_all:Nnn \replace_str { Ύ } { Υ }
	\tl_replace_all:Nnn \replace_str { Ώ } { Ω }
	%    \tl_replace_all:Nnn \replace_str { Ϊ } { Ι }
	%    \tl_replace_all:Nnn \replace_str { Ϋ } { Υ }
	\tl_use:N \replace_str
}
\ExplSyntaxOff
\renewcommand\mainmatter{%
	\if@openright%
	\cleardoublepage%
	\else%
	\clearpage%
	\fi%
	\@mainmattertrue%
	\fancyhf{}%
	\ifthenelse{\boolean{@tufte@twoside}}%
	{% two-side
		\renewcommand{\chaptermark}[1]{\markboth{##1}{}}%
		\fancyhead[LE]{\thepage\quad\smallcaps{\newlinetospace{\removeaccent{\plaintitle}}}}% book title
		\fancyhead[RO]{\smallcaps{\newlinetospace{\removeaccent{\leftmark}}}\quad\thepage}% chapter title
	}%
	{% one-side
		\fancyhead[RE,RO]{\smallcaps{\newlinetospace{\removeaccent{\plaintitle}}}\quad\thepage}% book title
	}%
}
\makeatother


%%
% Book metadata
\title{Επικοινωνία υποσυστημάτων στον νανοδορυφόρο AcubeSAT}
\author[Αντωνιος Κερεμιδης]{Αντωνιος Κερεμιδης}
\publisher{\ensuregreek{Αριστοτελειο Πανεπιστημιο Θεσσαλονικης}}

\hypersetup{
	pdftitle={Επικοινωνία υποσυστημάτων στον νανοδορυφόρο AcubeSAT},
	pdfsubject={Επικοινωνία υποσυστημάτων στον νανοδορυφόρο AcubeSAT},
	pdfauthor={Αντώνιος Κερεμίδης},
	addtopdfcreator={tufte-book class}
}

\input{glossary-el.tex}

\begin{document}
\relsize{1.1}

\sloppy
% \renewcommand*{\itemautorefname}{Στοιχείο}
% \renewcommand*{\figureautorefname}{Σχήμα}
% \renewcommand*{\chapterautorefname}{Κεφάλαιο}
% \renewcommand*{\sectionautorefname}{Ενότητα}
% \renewcommand*{\subsectionautorefname}{Ενότητα}
% \renewcommand*{\tableautorefname}{Πίνακα}
% \newcommand*{\algorithmautorefname}{Αλγόριθμος}
% \renewcommand{\appendixpagename}{Παραρτήματα}
% \newcommand{\Παράρτημαautorefname}{Παράρτημα}

% \renewcommand*{\algorithmautorefname}{Αλγόριθμος}
\renewcommand*{\figurename}{Σχήμα}
\renewcommand*{\tablename}{Πίνακας}
\renewcommand*{\contentsname}{Περιεχόμενα}
\renewcommand*{\listfigurename}{Κατάλογος Σχημάτων}
\renewcommand*{\listtablename}{Κατάλογος Πινάκων}
\sisetup{range-phrase={ ως }}

\renewcommand{\crefpairconjunction}{ και\nobreakspace}%
\renewcommand{\creflastconjunction}{ και\nobreakspace}%
\renewcommand{\crefpairgroupconjunction}{ και\nobreakspace}%
\renewcommand{\creflastgroupconjunction}{, και\nobreakspace}%

\crefname{figure}{\g{Σχήματος}}{\g{Σχημάτων}}
\Crefname{figure}{\g{Σχή\-μα}}{\g{Σχήματα}}
\crefname{table}{\g{Πίνακας}}{\g{Πίνακες}}
\Crefname{table}{\g{Πίνακα}}{\g{Πίνακες}}
\crefname{enumi}{\g{Στοιχείου}}{\g{Στοιχείων}}
\Crefname{enumi}{\g{Στοιχείο}}{\g{Στοιχεία}}
\Crefname{chapter}{\g{Κεφάλαιο}}{\g{Κεφάλαια}}
\crefname{section}{\g{Ενότητας}}{\g{Ενοτήτων}}
\Crefname{section}{\g{Ενότητα}}{\g{Ενότητες}}
\crefname{subsection}{\g{Ενότητας}}{\g{Ενοτήτων}}
\Crefname{subsection}{\g{Ενότητα}}{\g{Ενότητες}}
\Crefname{appendix}{\g{Παράρτημα}}{\g{Παραρτήματα}}
\Crefname{algorithm}{\g{Αλγόριθμος}}{\g{Αλγόριθμοι}}
\Crefname{lst}{\g{Κώδικας}}{\g{Κώδικες}}


% Front matter
%\frontmatter

% r.1 blank page
%\blankpage

% r.3 full title page
\makeatletter
\renewcommand{\maketitle}{%
	\newpage
	\global\@topnum\z@% prevent floats from being placed at the top of the page
	\begingroup
	\setlength{\parindent}{0pt}%
	\setlength{\parskip}{4pt}%
	\let\@@title\@empty
	\let\@@author\@empty
	\let\@@date\@empty
	\thispagestyle{empty}
	\begin{fullwidth}
		\vfill
		\begin{center}
			\href{https://www.auth.gr/}{\includegraphics[width=.8\textwidth]{auth_logo_text}}\par
			\vspace{1cm}
			\LARGE\textsc{Διπλωματικη Εργασια}\par
			\vspace{6ex}
			\hrule
			\vspace{4ex}
			\Huge\textbf{Επικοινωνία υποσυστημάτων στον νανοδορυφόρο AcubeSAT}\\[1ex]
			\vspace{2.7ex}
			\hrule

			\vspace{4ex}

			\Large
			\begin{tabular}{ll}
				\emph{Συγγραφέας:} & \href{https://github.com/toniker}{Αντώνιος \textsc{Κερεμιδης} \normalsize (\fontfamily{pplx}\selectfont 9717)}
				\\[1.5ex]
				\emph{Επιβλέπων:} & \href{http://ee.auth.gr/en/school/faculty-staff/electronics-computers-department/hatzopoulos-alkiviadis/}{Καθ. Αλκιβιάδης \textsc{Χατζοπουλος}}
			\end{tabular}

			\vspace{6ex}

			\large \textit{Η διπλωματική εργασία κατατίθεται για την \\ εκπλήρωση των υποχρεώσεων για λήψη διπλώματος}\\[0.3cm] % University requirement text
			\textit{στην}\\[0.4cm]
			\href{https://www.eng.auth.gr/gr/archiki.html}{Πολυτεχνική Σχολή}
			\\
			\href{https://ee.auth.gr/}{Τμήμα Ηλεκτρολόγων Μηχανικών \& Μηχανικών Υπολογιστών}
			\\[1cm] % Research group name and department name

			\vfill

			{\large \selectlanguage{greek}\today{}}\\[4cm] % Date % TODO

		\end{center}
		\vfill
	\end{fullwidth}
	\endgroup
	\thispagestyle{plain}% suppress the running head
	\tuftebreak% add some space before the text begins
	\@afterindentfalse\@afterheading% suppress indentation of the next paragraph
}
\makeatother
\maketitle

% v.4 copyright page
\newpage
\begin{fullwidth}
~\vfill
\thispagestyle{empty}
\setlength{\parindent}{0pt}
\setlength{\parskip}{\baselineskip}
Copyright \copyright\ \the\year\ Αντώνιος Κερεμίδης

\par\smallcaps{Δημοσιευτηκε απο το \thanklesspublisher}

\justify

\par Αυτή η εργασία χορηγείται με άδεια Creative Commons Αναφορά Δημιουργού 4.0 Διεθνές (CC BY 4.0 --- η ``Άδεια'')· το κείμενο του παρόντος δεν επιτρέπεται να χρησιμοποιηθεί παρά μόνο με βάση την Άδεια. Για να δείτε ένα αντίγραφο αυτής της άδειας, επισκεφτείτε το
\url{https://creativecommons.org/licenses/by/4.0/legalcode.el}, ή δείτε μια "αναγνώσιμη από άνθρωπο" σύνοψη στο \url{https://creativecommons.org/licenses/by/4.0/deed.el}.\index{license}

\par Η εργασία ετοιμάστηκε χρησιμοποιώντας \LaTeX{} με το πρότυπο \href{https://ctan.org/pkg/tufte-latex?lang=en}{\texttt{tufte-latex}} και τις βελτιώσεις του \href{https://github.com/lalider/tufte-latex-thesis}{\texttt{tufte-latex-thesis}}.

\par Το AcubeSAT project εκτελείται με την υποστήριξη του Education Office του \href{https://www.esa.int/}{Ευρωπαϊκού Οργανισμού Διαστήματος}, στα πλαίσια του \href{https://www.esa.int/Education/CubeSats_-_Fly_Your_Satellite/}{προγράμματος Fly Your Satellite!}

\par Οι απόψεις που εκφράζονται στο παρόν από τους συγγραφείς δεν μπορούν \smallcaps{σε καμια περιπτωση να θεωρηθει πως εκφραζουν} την επίσημη άποψη, ή υποστήριξη του Ευρωπαϊκού Οργανισμού Διαστήματος.

\par\textit{Εκδόθηκε στις {\selectlanguage{greek}\today{}}  (\texttt{\gitcommit}: \gitcommitmessage)}
\end{fullwidth}

% r.5 contents
\tableofcontents

\begin{fullwidth}
\listoffigures

\listoftables

% \chapter*{Μεταφράσεις ξενόγλωσσης ορολογίας}

% \bgroup
% \setlength\parskip{.8ex}
% % \printacronyms[include=glossary,template=glossary]
% \egroup

%\chapter*{List of Acronyms}
%\acuseall%
\bgroup
\setlength\parskip{1ex}
\printacronyms[pages={display=all,seq/use=false},exclude = {glossary},name = {Ακρωνύμια}]
\egroup

\end{fullwidth}

% r.9 introduction
\cleardoublepage

\chapter*{Περίληψη}

\begin{fullwidth}
	\centering
	\begin{minipage}{107mm}
		\justify
		\g{Η αξιόπιστη επικοινωνία των υποσυστημάτων σε ένα νανοδορυφόρο αποτελεί έναν κρίσιμο παράγοντα για την επιτυχία μίας διαστημικής αποστολής. Σε αυτό το πλαίσιο, η παρούσα διπλωματική εργασία εστιάζει στην χρήση του} \ac{CAN} Bus \g{ως πρωτόκολλο επικοινωνίας για τη σύνδεση και αλληλεπίδραση υποσυστημάτων σε ένα νανοδορυφόρο τύπου} CubeSat\g{ μεγέθους} 3U (Units)\g{. Αναλύοντας το υλικό, το πρωτόκολλο και το λογισμικό που υλοποιήθηκε, αυτή η εργασία θα εξετάσει τις τεχνικές, τις προκλήσεις και τις λύσεις που εφαρμόστηκαν για τη διασφάλιση αξιόπιστης επικοινωνίας μεταξύ των υποσυστημάτων ενός τέτοιου δορυφόρου. Η εργασία έγινε στη \href{https://www.esa.int/Education/CubeSats_-_Fly_Your_Satellite/FYS_-_Programme_phases}{φάση Δέλτα} στα πλαίσια υλοποίησης του νανοδορυφόρου} AcubeSAT, \g{ο οποίος υλοποιείται από φοιτητές, κυρίως του Αριστοτελείου Πανεπιστημίου Θεσσαλονίκης, στο πλαίσιο του προγράμματος} Fly Your Satellite! 3 \g{του εκπαιδευτικού γραφείου του Ευρωπαϊκού Οργανισμού Διαστήματος. Στην περίπτωση του νανοδορυφόρου} AcubeSAT \g{το} \ac{CAN} Bus \g{χρησιμοποιείται για την μεταφορά εντολών, δεδομένων πειράματος και για την εκτέλεση διαδικασιών εντοπισμού, ανίχνευσης και αποσφαλμάτωσης των υποσυστημάτων.}
    \end{minipage}
\end{fullwidth}

\chapter*{Abstract}

\begin{fullwidth}
	\centering
	\begin{minipage}{107mm}
		\justify
		Achieving reliable communication between subsystems on a nanosatellite is a critical factor in the success of its space mission. In this context, this undergraduate thesis focuses on the use of the \ac{CAN} Bus as a medium for the communication and interaction of subsystems in a 3U (Units) CubeSat-type nanosatellite. By analyzing the hardware, protocol and software implemented, this paper will examine the techniques, challenges and solutions implemented to ensure reliable communication between the subsystems of such a satellite. The work was done in the \href{https://www.esa.int/Education/CubeSats_-_Fly_Your_Satellite/FYS_-_Programme_phases}{phase Delta} of the implementation of the AcubeSAT nanosatellite, which is executed by students, consisting mainly of undergraduates at the Aristotle University of Thessaloniki. The project is part of the program \emph{Fly Your Satellite! 3} conducted by the Education Office of the European Space Agency. In the case of the AcubeSAT nanosatellite, the \ac{CAN} Bus is used for the transfer of commands, experiment data, and for the execution of subsystems' fault detection, isolation and recovery procedures.
	\end{minipage}
\end{fullwidth}
\chapter*{Ευχαριστίες}

\g{
Είμαι πολύ ευγνώμων για την υποστήριξη που έλαβα κατά τη διάρκεια της διπλωματικής μου εργασίας. Θέλω να ευχαριστήσω τον καθηγητή Αλκιβιάδη Χατζόπουλο για την υποστήριξή του στην εργασία και το έργο της ομάδας. Επίσης, θέλω να ευχαριστήσω τους γονείς, φίλους και το σημαντικό μου άνθρωπο που στάθηκαν δίπλα μου τα τελευταία χρόνια. Τέλος, θέλω να ευχαριστήσω τα μέλη της ομάδας για την συνεργασία επάνω στο πρότζεκτ, και ιδιαίτερα το υποσύστημα του }OBC\g{ για την συνεχή αλληλοϋποστήριξη. Η εργασία αυτή στέκεται στους ώμους χιλιάδων ωρών εργασίας από τα πιο δημιουργικά άτομα που έχω γνωρίσει. Είμαι πολύ χαρούμενος που ολοκληρώσαμε τη σταδιοδρομία μου μαζί και είμαι περήφανος που είχα την ευκαρία να συνεισφέρω σε αυτό το έργο.
}

\mainmatter

\chapter{Εισαγωγή}
\section{Επιστημονική Περιοχή}
Η παρούσα εργασία ασχολείται με την Αεροδιαστημική Μηχανική, και πιο συγκεκριμένα την τεχνολογία επικοινωνίας των υποσυστημάτων σε ένα δορυφόρο. Καθώς οι δορυφόροι καλούνται να εκτελέσουν ένα σύνολο από διαφορετικές λειτουργίες, η έγκαιρη και αξιόπιστη επικοινωνία μεταξύ των υποσυστημάτων τους είναι μία ύψιστης σημασίας συνθήκη για την επιτυχία της αποστολής.

\begin{marginfigure}
	\includegraphics[width=0.7\textwidth]{media/images/endurosat-platforms/1u.png}
	\caption{Πλατφόρμα CubeSat μεγέθους 1U από την EnduroSat \parencite{1UEndurosat}}
\end{marginfigure}

\begin{marginfigure}
	\includegraphics[width=0.7\textwidth]{media/images/endurosat-platforms/3u.png}
	\caption{Πλατφόρμα CubeSat μεγέθους 3U από την EnduroSat \parencite{3UEndurosat}}
\end{marginfigure}

Οι δορυφόροι σε τροχιά εκτελούν σημαντικές διεργασίες όπως τηλεπικοινωνίες, μετάδοση σημάτων πλοήγησης, παρατήρηση της Γης, επιστημονική έρευνα και άλλα, και παρέχουν πολύτιμες πληροφορίες για την ανθρώπινη ζωή και την έρευνα στην Γη, τις οποίες δεν θα μπορούσαμε να αποκτήσουμε με άλλο τρόπο. Οι πληροφορίες που παρέχονται από διαστημικές αποστολές έχουν γίνει πλέον αναπόσπαστο κομμάτι της σύγχρονης επιστήμης. Το φαινόμενο αυτό οδηγεί σε συνεχώς αυξανόμενο ρυθμό διαστημικών αποστολών, με νέες ιδέες για διαστημική έρευνα και υπηρεσίες κοινής ωφέλειας. Πιο συγκεκριμένα, έχοντας αυτή την στιγμή περισσότερους από 11701 δορυφόρους στο διάστημα εκ των οποίων οι 9125 βρίσκονται εν ενεργεία \dualcite{orbitingnow}, καταλαβαίνουμε ότι συνεχώς αυξάνονται οι απαιτήσεις για αξιοπιστία και ελάττωση κόστους.

Μετά την εκτόξευσή τους, οι δορυφόροι παραμένουν σε τροχιά μέχρι την ολοκλήρωση της αποστολής τους. Ανάλογα με το σχεδιασμό της αποστολής και την αρχική τροχιά, οι δορυφόροι έχουν δύο πιθανά σενάρια για το τέλος της ζωής τους. Στο πρώτο σενάριο ο δορυφόρος συνεχίζει τη τροχιά του γύρω από τη Γη για μερικούς μήνες, με τα ανώτερα στρώματα της ατμόσφαιρας να επιβραδύνουν τη τροχιά του, έως ότου η ταχύτητά του να μην είναι αρκετή και αυτός να επανέλθει σε πορεία σύγκρουσης με τη Γη. Κατά την επανείσοδο του δορυφόρου στην ατμόσφαιρα, λόγω της τεράστιας θερμότητας που αναπτύσσεται ο δορυφόρος καίγεται ολοσχερώς, με ελάχιστα μικροσκοπικά σωματίδια να φτάνουν στη Γη \dualcite{MDAR_ARPT}. Η δεύτερη επιλογή είναι ο δορυφόρος να παραμείνει στο διάστημα ως διαστημικά σκουπίδια.

\begin{marginfigure}
	\includegraphics[width=0.7\textwidth]{media/images/endurosat-platforms/6u.png}
	\caption{Πλατφόρμα CubeSat μεγέθους 6U από την EnduroSat \parencite{6UEndurosat}}
\end{marginfigure}

\begin{marginfigure}
	\includegraphics[width=0.7\textwidth]{media/images/endurosat-platforms/12u.png}
	\caption{Πλατφόρμα CubeSat μεγέθους 12U από την EnduroSat. Στην συγκεκριμένη φωτογραφία ο μηχανισμός των ηλιακών πάνελ είναι στην \emph{ανοικτή} θέση. \parencite{12UEndurosat}}
\end{marginfigure}

Η ανάπτυξη διαστημικών συστημάτων αντιμετωπίζει έναν σημαντικότερο βαθμό δυσκολίας, λόγω της φύσης των αποστολών. Οι ακραίες θερμοκρασίες, η μεγάλη απόσταση, η αδυναμία αποσφαλμάτωσης, οι ακτινοβολίες υψηλής ενέργειας και τα μηχανικά φορτία της εκτόξευσης είναι λόγοι που συνδράμουν στην υψηλή δυσκολία των διαστημικών αποστολών. Για αυτό το σκοπό, θέσεις όπως υπεύθυνοι μηχανικής συστημάτων (Systems Engineering), διασφάλισης ποιότητας (Product Assurance) και αξιοπιστίας συστημάτων (Reliability Engineering) είναι πλέον απαραίτητοι στα πρότζεκτ αεροδιαστημικής. Αυτές οι επιπρόσθετες διεργασίες προστίθενται στον ήδη μεγάλο φόρτο που περικλείει μία ερευνητική διαδικασία, οδηγώντας το χρονικό και οικονομικό κόστος στα ύψη.

Για λόγους οικονομίας και κόστους, σε αρκετές περιπτώσεις προτιμούνται οι πλέον δημοφιλείς νανοδορυφόροι τύπου CubeSat. Τα CubeSats πρωτοεμφανίστηκαν το 2003 με την αποστολή CanX 1 \dualcite{canx1} και αποτελούν πλέον μία από τις πιο οικονομικά αποδοτικές επιλογές. Το χαμηλό τους μέγεθος, καθώς και η μικρή σχετικά πολυπλοκότητα, έχουν επιτρέψει πανεπιστήμια και οργανισμούς παγκοσμίως να εκτοξεύσουν πάνω από 2410 CubeSats μέχρι και το 2023.

\begin{marginfigure}
	\includegraphics[width=1\linewidth]{diagrams/nanosats-status.png}
	\label{diag:nanosats-status}
	\caption[Αποστολές νανοδορυφόρων ανά τη τρέχουσα κατάσταση]{Αποστολές νανοδορυφόρων ανά τη τρέχουσα κατάσταση. Πηγή: Erik Kulu, Nanosats Database, \href{https://www.nanosats.eu}{www.nanosats.eu}}
\end{marginfigure}
Τα CubeSats κατασκευάζονται με δομικές μονάδες διαστάσεων 10 × 10 × 10 εκατοστά, που αναφέρονται ως "Units". Οι δορυφόροι συνήθως δημιουργούνται "στοιβάζοντας" αυτές τις μονάδες, δημιουργώντας δορυφόρους με μεγέθη 1U, 1.5U, 2U, 3U, 6U και 12U. Κάθε Unit έχει τη δυνατότητα να υποστηρίξει έως 2 κιλά. Σε εσωτερικό επίπεδο, τα CubeSats αποτελούνται από ηλεκτρονικά εξαρτήματα χαμηλού κόστους που είναι διαθέσιμα εμπορικά, γνωστά ως Commercial Off-The-Shelf (COTS). Συνήθως εκτοξεύονται σε Low Earth Orbit (LEO) ως δευτερεύοντα φορτία σε εκτοξεύσεις μεγαλύτερων δορυφόρων και διατηρούνται ενεργά για περίπου 1 έως 3 χρόνια.
\begin{marginfigure}
	\includegraphics[width=1\linewidth]{media/images/flatsat.png}
	\label{fig:flatsat}
	\caption{Δομή FlatSat για τα υποσυστήματα του AcubeSAT}
\end{marginfigure}

\section{Σκοπός και συνεισφορά της διπλωματικής}
Η παρούσα εργασία αποσκοπεί στην προσφορά ενός ολοκληρωμένου συστήματος επικοινωνίας για τα υποσυστήματα του AcubeSAT. Η αποστολή του νανοδορυφόρου AcubeSAT, την παρούσα στιγμή βρίσκεται στη φάση Δέλτα του προγράμματος Fly Your Satellite! 3, η οποία περιλαμβάνει το πλάνο Manufacturing, Assembly, Integration, Verification. Ως αποτέλεσμα, όλο και περισσότερα συστήματα του δορυφόρου βρίσκονται στη διαδικασία ανάπτυξης που περιλαμβάνει τη στενά συνδεδεμένη ενσωμάτωση υλικού και λογισμικού. Όπως είναι φυσικό, ένα από αυτά τα συστήματα είναι ο δίαυλος του \ac{CAN} Bus, ο οποίος είναι υπεύθυνος για την επικοινωνία μεταξύ των υποσυστημάτων του δορυφόρου. \marginnote{\href{https://www.esa.int/Education/CubeSats_-_Fly_Your_Satellite/Fly_Your_Satellite!_programme}{Σύνδεσμος για την αρχική σελίδα του προγράμματος Fly Your Satellite! του Εκπαιδευτικού Γραφείου της ESA}} Η εργασία αυτή αποτελεί την πρώτη προσπάθεια υλοποίησης του λογισμικού που εκτελεί τις διαδικασίες του διαύλου \ac{CAN} Bus στον νανοδορυφόρο AcubeSAT. Ο δεύτερος σκοπός που επιτεύχθηκε από την εργασία είναι η επιβεβαίωση λειτουργικότητας του υλικού που σχεδιάστηκε για χρήση στο \ac{OBC}/\ac{ADCS} Board. Η λειτουργία του \ac{CAN} Bus βοήθησε στην επικύρωση του συστήματος επικοινωνίας της πλακέτας με τα υποσυστήματα που βρίσκονται εκτός αυτής, όπως και την διεξαγωγή των δοκιμών της πλακέτας υπό περιβαλλοντικές συνθήκες διαστήματος. Ένας επιπλέον σκοπός της ανάπτυξης του διαύλου σε αυτό το στάδιο κατασκευής του δορυφόρου, είναι η επικοινωνία των υποσυστημάτων στην δομή FlatSat (δείτε \Cref{fig:flatsat}), όπου θα προσομοιωθεί η λειτουργία του δορυφόρου με όλα τα υποσυστήματα σε λειτουργία. Στη δομή FlatSat, όλα τα υποσυστήματα του δορυφόρου τοποθετούνται σε μία επίπεδη πλακέτα, όπου οι διασυνδέσεις μεταξύ τους είναι ευκολότερο να εξεταστούν με λεπτομέρεια σε αντίθεση με την τελική διαμόρφωση. Η δομή FlatSat προσφέρει βολικά σημεία εξόδου για πολλά σήματα που παράγονται από τα υποσυστήματα, όπως τα σήματα του διαύλου \ac{CAN} Bus, τις σειριακές εξόδους \ac{UART} και τα σήματα αποσφαλμάτωσης \ac{SWD}. 

Τέλος, η εργασία αυτή προσφέρει μία αναλυτική περιγραφή για τον τρόπο λειτουργίας του διαύλου \ac{CAN} Bus στο νανοδορυφόρο AcubeSAT, προς μελλοντική αναφορά σε εργασίες που αφορούν το σύστημα.

\section{Διάρθρωση και Δομή}
Η εργασία ξεκινάει με την περίληψη της αποστολής AcubeSAT στο \Cref{chap:acubesat}, που αποτελεί την κύρια αφορμή και πλαίσιο συγγραφής της. Συνεχίζοντας, αναλύονται οι αποφάσεις που οδήγησαν στην επιλογή του \ac{CAN} Bus ως διαύλου εύρωστης επικοινωνίας μεταξύ των υποσυστημάτων του νανοδορυφόρου. Το επόμενο κομμάτι αναφέρεται στην λειτουργικότητα, ιστορία και υψηλού-επιπέδου περιγραφή του \ac{CAN} Bus. Το \Cref{chap:design-choices} αναλύει τις επιλογές της ομάδας που αφορούν τις λεπτομέρειες στην υλοποίηση του διαύλου.

\par Έπειτα, το \Cref{chap:implementation} αναλύει την εργασία μου για την υλοποίηση του διαύλου, στο σύστημα μικροελεγκτή, λειτουργικού και του υπόλοιπου λογισμικού που αναπτύχθηκε από την ομάδα. Τέλος, στο \Cref{chap:usage} αναφέρεται η πρακτική εφαρμογή της εργασίας στο έως σήμερα υλοποιημένο έργο του πρότζεκτ.

\chapter{Ο νανοδορυφόρος AcubeSAT}
\label{chap:acubesat}

\begin{marginfigure}
	\centering
	\includegraphics{media/acubesat_patch.png}
	\caption{Το λογότυπο του AcubeSAT}
	\label{acubesat-logo}

	\includegraphics[height=10cm]{media/images/acubesat-new.png}
	\caption{Προβολή του νανοδορυφόρου AcubeSAT}
	\label{acubesat-render}
\end{marginfigure}

\section{Εισαγωγή}
Ο νανοδορυφόρος AcubeSAT δημιουργήθηκε από τη φοιτητική ομάδα SpaceDot, υπό την αιγίδα του προγράμματος Fly Your Satellite! 3, του εκπαιδευτικού γραφείου του Ευρωπαϊκού Οργανισμού Διαστήματος. Η ομάδα εδρεύει στο Αριστοτέλειο Πανεπιστήμιο Θεσσαλονίκης, το οποίο παρέχει χώρους εργασίας και χρηματοδότηση, ενώ παράλληλα οι καθηγητές του συνδράμουν στην προσπάθεια της ομάδας. Το project απασχολεί περίπου 90 φοιτητές, οι οποίοι φοιτούν κατά κύριο λόγο στο ΑΠΘ. Ο AcubeSAT είναι ένας νανοδορυφόρος τύπου CubeSat, μεγέθους 3U, με διαστάσεις ($34 \times 10 \times 10$ εκατοστά) και βάρος $4200$ γραμμάρια. Ένα CubeSat συνήθως αποτελεί δευτερεύον payload ενός δορυφόρου, και \emph{αφήνεται} σε τροχιά γύρω από την Γη. Το CubeSat θα λειτουργεί εντελώς αυτόνομα και δεν θα είναι συνδεδεμένο με κανένα τρόπο με το δορυφόρο μετά την έναρξη λειτουργίας του. Καθώς ένα CubeSat δεν έχει τρόπο για να επηρεάσει την τροχιά του, παρά μόνο τον προσανατολισμό του, είναι απαραίτητο εξ'αρχής να τεθεί σε τροχιά που καλύπτει τις ανάγκες του. Στην περίπτωση του AcubeSAT, αυτή η τροχιά θα είναι σε ύψος περίπου 500 χλμ πάνω από την επιφάνεια της Γης. Η τροχιά θα έχει αρκετή ταχύτητα ώστε να διαρκέσει ενάμιση χρόνο προτού ο νανοδορυφόρος πέσει στην ατμόσφαιρα και καταστραφεί λόγω θερμότητας κατά την επανείσοδο \dualcite{MDO}.

\section{Αποστολή}
Ο σκοπός του AcubeSAT είναι να μελετήσει την ανάπτυξη των ευκαρυωτικών κυττάρων του \emph{Saccharomyces cerevisiae} σε συνθήκες διαστήματος \dualcite{DDJF_SYS}. Ο παραπάνω οργανισμός είναι ένας μύκητας, ο οποίος ανήκει στην κατηγορία των μονοκύτταρων ευκαρυωτικών οργανισμών. 

Χρησιμοποιώντας την ομοιότητα που εμφανίζει με τα ανθρώπινα κύτταρα μπορούμε να εξάγουμε συμπεράσματα για την ανάπτυξη των κυττάρων σε μικροσκοπικό επίπεδο κατά τη διάρκεια της ζωής στο διάστημα. Όντας έξω από την προστατευτική ατμόσφαιρα της Γης, τα κύτταρα δέχονται μεγαλύτερες δόσεις ακτινοβολίας, που προέρχεται από τις ζώνες Van Allen, το South Atlantic Anomaly και τους πόλους της Γης \dualcite{MDO}. 

Συγκεκριμένα, ο σκοπός της αποστολής είναι να μελετηθεί η επιρροή της έλλειψης βαρύτητας και η ακτινοβολία που αναφέρθηκε παραπάνω σε τρείς καλλιέργιες του \emph{Saccharomyces cerevisiae}, συγκρίνοντας την ανάπτυξή τους στο διάστημα σε σύγκριση με τη Γη. Για τη σύγκριση των καλλιεργειών, ο νανοδορυφόρος είναι εξοπλισμένος με ένα σύστημα το οποίο θα φωτογραφίζει τα κύτταρα σε διάφορα στάδια ανάπτυξης. Οι φωτογραφίες θα μεταδίδονται στο σταθμό βάσης και θα συγκρίνονται με μία αντίστοιχη καλλιέργεια στη Γη.

\section{Υποσυστήματα}
Η ομάδα κατασκευάζει 4 από τα υποσυστήματα του νανοδορυφόρου, τα οποία στεγάζονται στο πάνω μέρος του.
\subsection{Υποσύστημα Προσδιορισμού και Ελέγχου Προσανατολισμού (\ac{ADCS})}
Το υποσύστημα του \ac{ADCS} είναι υπεύθυνο για τον προσανατολισμό του δορυφόρου όσο αυτός βρίσκεται σε τροχιά. Για να το επιτύχει αυτό, χρησιμοποιούονται δύο μαγνητόμετρα υψηλής ακριβείας. Παρόλο που αρκούν οι μετρήσεις από ένα μόνο μανγητόμετρο, ο δορυφόρος έχει εξοπλιστεί με ένα δευτερεύον για περίπτωση όπου χρειαστεί για λόγους ανίχνευσης και αντιμετώπισης βλαβών. Για λόγους εξοικονόμησης ενέργειας, χρησιμοποιείται η τεχνική \textbf{cold redundancy}, όπου το δευτερεύον μαγνητόμετρο είναι απενεργοποιημένο έως ότου εντοπιστεί βλάβη στο κύριο.

Το \ac{ADCS} λειτουργεί υπό τρία διαφορετικά προφίλ, για να καλύψει τις ανάγκες του δορυφόρου ανά πάσα στιγμή. Μόνο ένα προφίλ είναι ενεργοποιημένο τη φορά, και επιλέγονται αυτόματα ανάλογα με τη θέση και τη δραστηριότητα του δορυφόρου \dualcite{DDJF_AOCS}.
\begin{enumerate}
    \item \textbf{Nadir Pointing}: Ο δορυφόρος στρέφει τη πλευρά +X ώστε να κοιτάζει προς τη Γη. Αυτή η κατεύθυνση στρέφει την κατευθυντική κεραία του δορυφόρου προς την κατάλληλη κατεύθυνση για να εξασφαλίσει ζεύξη, όταν αυτός βρίσκεται πάνω από τον σταθμό βάσης. 
    \item \textbf{Sun Pointing}: Ο δορυφόρος στρέφεται προς τον ήλιο με κατάλληλο τρόπο, ώστε να μεγιστοποιηθεί η παραγωγή ενέργειας από τα ηλιακά πάνελ. Αυτό το προφίλ ενεργοποιείται ανάμεσα σε περάσματα από τον σταθμό βάσης, έτσι ώστε να εξασφαλιστεί θετικό ισοζύγιο ενέργειας στις μπαταρίες.
    \item \textbf{Detumbling}: Ο δορυφόρος κάνει τις κατάλληλες κινήσεις για να φτάσει τη γωνιακή του ταχύτητα στο μηδέν. Αυτό επιτυγχάνεται με χρήση ενός απλού αλγορίθμου αυτομάτου ελέγχου και τις μετρήσεις του μαγνητομέτρου. Αυτή η λειτουργία ενεργοποιείται όταν ο δορυφόρος δεν έχει άμεση ανάγκη να βρίσκεται σε κάποιο από τα άλλα προφίλ. Η διατήρηση της γωνιακής ταχύτητας κοντά στο μηδέν, βοηθά την ανάκτηση ελέγχου όταν χρειαστεί να προσανατολιστεί ο δορυφόρος σε άλλη κατεύθυνση. Ένα επιπλέον πλεονέκτημα είναι ότι βοηθά στην εξασφάλιση ραδιοζεύξης με τη χρήση της κατευθυντικής κεραίας.
\end{enumerate}

\subsection{Υποσύστημα Τηλεπικοινωνιών (\ac{COMMS})}
Το υποσύστημα τηλεπικοινωνιών είναι υπεύθυνο για την επικοινωνία με το σταθμό βάσης, όσο ο δορυφόρος βρίσκεται σε τροχιά. Για να επιτύχει τους σκοπούς του, ο δορυφόρος χρησιμοποιεί δύο είδη κεραιών. Μία από τις κεραίες του δορυφόρου λειτουργεί στο S-Band εύρος συχνοτήτων. Ο σκοπός αυτής της κεραίας είναι η μεταφορά των δεδομένων των επιστημονικών πειραμάτων σε μορφή \ac{PNG} φωτογραφιών. Καθώς αυτή η κεραία είναι κατευθυντική απαιτεί οπτική επαφή με τον σταθμό βάσης. Η ιδιότητα αυτή σημαίνει ότι η μεταφορά δεδομένων μέσω S-Band χρησιμοποιεί κατά μέσο όρο ένα παράθυρο 270 δευτερολέπτων, με κάθε πέρασμα πάνω από το σταθμό βάσης. Η δεύτερη κεραία διπόλων χρησιμεύει στην συνεχή επικοινωνία με τον δορυφόρο, χρησιμοποιώντας την μπάντα \ac{UHF}. Χάρη στη χαμηλή ταχύτητα μεταφοράς δεδομένων που προσφέρεται από το φάσμα των \ac{UHF}, η επικοινωνία με τον δορυφόρο περιορίζεται σε βασικές τηλε-εντολές και τηλεμετρία \dualcite{DDJF_TTC}.


Για τις διεργασίες του υποσυστήματος τηλεπικοινωνιών χρησιμοποιείται η πλακέτα SatNOGS \ac{COMMS} της Libre Space Foundation. Όλο το υποσύστημα έχει υλοποιηθεί με βάση τα τηλεπικοινωνιακά πρότυπα \ac{CCSDS} \dualcite{DDJF_TTC}.

\begin{marginfigure}
	\includegraphics{media/images/satnogs-comms.png}
	\caption{Το SatNOGS \ac{COMMS} Board της Libre Space Foundation}
	\label{fig:satnogs-comms}
\end{marginfigure}

\marginnote{
	Το \href{URL}{Libre Space Foundation} είναι ένα μη κερδοσκοπικό ίδρυμα που ιδρύθηκε το 2015 στην Ελλάδα από τους δημιουργούς του έργου \href{https://satnogs.org/}{SatNOGS}.
}

\subsection{Υποσύστημα Διαχείρισης Δεδομένων (\ac{OBDH})}
Το υποσύστημα διαχείρισης δεδομένων είναι υπεύθυνο για τον σχεδιασμό των διεπαφών δεδομένων εντός του δορυφόρου. Ένα σημαντικό κατόρθωμα του υποσυστήματος, αλλά και της ευρύτερης ομάδας, είναι ο σχεδιασμός και υλοποίηση της πλακέτας που στεγάζει τα υποσυστήματα του \textbf{On-Board Computer} και του \textbf{Attitude Determination and Control Subsystem}.

Η πλακέτα που δημιουργήθηκε ακολουθεί το πρότυπο LibreCube και περιλαμβάνει μνήμες \ac{MRAM}, \ac{NAND} και τον μικροελεγκτή που στεγάζει το \ac{OBC} στην επάνω πλευρά του. Στην κάτω πλευρά της πλακέτας στεγάζεται ο μικροελεγκτής για το υποσύστημα του \textbf{\ac{ADCS}}, μαζί με το μαγνητόμετρο και τα δύο γυροσκόπια που απαιτεί το υποσύστημα.

Το υποσύστημα του \ac{OBC} είναι υπεύθυνο για τον μηχανισμό ανίχνευσης, απομόνωσης και αντιμετώπισης βλαβών σε επίπεδο υποσυστημάτων για τον υπόλοιπο δορυφόρο. Χρησιμοποιώντας μηνύματα μέσω του \textbf{\ac{CAN} Bus}, μελετά τις παραμέτρους που αναφέρουν τα υπόλοιπα υποσυστήματα.\begin{marginfigure}
	\includegraphics[width=1\linewidth]{images/obc-pcb-physical.jpg}
	\label{fig:obc-pcb}
	\caption[Η πλακέτα του \ac{OBC}]{Η πλακέτα του \ac{OBC}. Τα υποσυστήματα \ac{OBC} και \ac{ADCS} στεγάζονται στην πλακέτα}
\end{marginfigure} Σε οποιοδήποτε σφάλμα που ανιχνεύεται στην επικοινωνία ή στα δεδομένα που λαμβάνονται, το \ac{OBC} είναι υπεύθυνο για την επαναφορά του προβληματικού υποσυστήματος. Η επαναφορά αυτή γίνεται με εντολές στο υποσύστημα \textbf{Electrical Power Supply} για \emph{power cycle}, το οποίο παρέχεται από την εταιρεία \emph{ISISPACE}.

\subsection{Υποσύστημα επιστημονικής μονάδας (\ac{SU})}

\begin{marginfigure}
	\includegraphics[width=1\linewidth]{images/payload-container.png}
	\label{fig:payload-container}
	\caption[Ηλεκτρονική απεικόνιση του payload]{Ηλεκτρονική απεικόνιση του payload. Τα εξαρτήματα που αφορούν το επιστημονικό πείραμα φαίνονται χρωματισμένα με χρυσό}
\end{marginfigure}
Το υποσύστημα επιστημονικής μονάδας (\acs{SU}) χρησιμοποιεί περίπου τα 2/3 του όγκου του δορυφόρου. Για την διεξαγωγή του πειράματος, το \ac{SU} περιλαμβάνει μία πλακέτα η οποία στεγάζει τον μικροελεγκτή που χρησιμοποιείται για τον έλεγχο των επιστημονικών οργάνων. Το επιστημονικό πείραμα απαιτεί την φωτογράφιση των φωσφορίζων κυττάρων σε τακτά χρονικά διαστήματα κατά τη διάρκεια της ανάπτυξής τους. Για τον σκοπό αυτό χρησιμοποιείται ένας πρωτοπόρος συνδυασμός από ένα Lab-on-a-chip, με μία κάμερα που καταγράφει την ανάπυτξη των κυττάρων του γένους \textit{Saccharomyces cerevisiae} \dualcite{DDJF_PL}.

Το πείραμα απαιτεί αρκετό υποστηρικτικό εξοπλισμό, ο οποίος περιλαμβάνεται στο \textbf{δοχείο πειράματος}, μία δομή αλουμινίου που βρίσκεται σε ατμοσφαιρική πίεση. Ένα από τα υποστηρικτικά εξαρτήματα είναι κυκλώματα θέρμανσης, ή αλλιώς heaters, για διαχείριση της θερμοκρασίας. Καθώς η θερμοκρασία του δορυφόρου κατά τη διάρκεια της τροχιάς του θα μεταβάλλεται, τρείς αισθητήρες θερμοκρασίας υψηλής ακριβείας θα δίνουν την είσοδο στο αυτόματο σύστημα ελέγχου, έτσι ώστε η θερμοκρασία του Lab-on-a-chip να διατηρείται σταθερή στους $30^o C \pm 2^oC$ \dualcite{DDJF_PL}.

Παραπάνω, η φωτογράφιση των κυττάρων απαιτεί την φωσφώρισή τους. Για να επιτευχθεί αυτό χρησιμοποιείται μία σειρά από \ac{led} φώτα, τοποθετημένα περιμετρικά γύρω από το φακό της κάμερας. Η κάμερα χρησιμοποιεί ορισμένα φίλτρα για την λειτουργία της ως μικροσκόπιο, τα οποία είναι τοποθετημένα ανάμεσα στο φακό και τα τσιπ μικρορευστομηχανικής.

\begin{marginfigure}
	\includegraphics[width=1\linewidth]{images/su-led.png}
	\label{fig:su-led}
	\caption[Ηλεκτρονική απεικόνιση της πλακέτας \ac{led} του payload]{Ηλεκτρονική απεικόνιση της πλακέτας \ac{led} του payload. Η πλακέτα που είναι τοποθετημένη περιμετρικά του φακού θα περιέχει τα \ac{led} που χρησιμοποιούνται για τη φωσφώριση των κυττάρων}
\end{marginfigure}
Τέλος, ο μικροελεγκτής του \ac{SU} βρίσκεται υπό τον έλεγχο ενός υδραυλικού συστήματος που περιλαμβάνει 2 αντλίες, 14 ηλεκτρικά ελεγχόμενες βαλβίδες και 3 σακούλες υγρών, τα οποία προορίζονται για την τροφή των κυττάρων και τη διαχείριση των παραγώγων τους.

\section{Επικοινωνία των υποσυστημάτων}

Όπως αναφέρθηκε παραπάνω, μία από τις αρμοδιότητες του υποσυστήματος OBDH είναι ο σχεδιασμός των διεπαφών δεδομένων εντός του δορυφόρου. 
Αναλύοντας πρωτόκολλα για επικοινωνία εντός του δορυφόρου, υπάρχουν πολλές επιλογές που αρμόζουν στις ανάγκες του AcubeSAT. Τα πρωτόκολλα που εξετάστηκαν είναι τα παρακάτω:
\begin{itemize}
	\item \textbf{\ac{UART}}: Ένα απλό και ευρέως χρησιμοποιούμενο πρωτόκολλο επικοινωνίας σε ενσωματωμένα συστήματα. Πρόκειται για ένα πρωτόκολλο επικοινωνίας από σημείο-προς-σημείο που χρησιμοποιεί δύο καλώδια για τη μετάδοση δεδομένων μεταξύ δύο κόμβων. Το \ac{UART} είναι ιδανικό για επικοινωνία μικρών αποστάσεων μεταξύ δύο κόμβων και μπορεί να χρησιμοποιηθεί για επικοινωνία πολλαπλών κόμβων με τη χρήση ενός συστήματος διαύλου όπως το EIA-422 ή το EIA-485 \dualcite{UARTNetworks}. Ωστόσο, το \ac{UART} δεν υποστηρίζει πολλαπλούς master, γεγονός που μπορεί να οδηγήσει σε προβλήματα ανταγωνισμού του διαύλου. Η χρήση \ac{UART} στο δορυφόρο περιορίστηκε σε εξόδους log μηνυμάτων, τα οποία βοηθούν την ομάδα στην αποσφαλμάτωση, όσο ακόμα ο δορυφόρος βρίσκεται στη διαδικασία κατασκευής και επικύρωσης (MAIVP) \dualcite{MAIVP}.
	\item \textbf{\ac{SPI}}: Ένα σύγχρονο σειριακό πρωτόκολλο επικοινωνίας που χρησιμοποιείται συνήθως σε ενσωματωμένα συστήματα. Χρησιμοποιεί τέσσερα καλώδια για τη μετάδοση δεδομένων μεταξύ δύο κόμβων: MOSI (Master Out Slave In), MISO (Master In Slave Out), SCLK (Serial Clock) και SS (Slave Select) \dualcite{SPICondensed_TechRef}. Το \ac{SPI} είναι ιδανικό για επικοινωνία υψηλής ταχύτητας μεταξύ δύο κόμβων και μπορεί να χρησιμοποιηθεί για επικοινωνία πολλαπλών κόμβων με τη χρήση ενός συστήματος διαύλου. Ωστόσο, η πολυπλοκότητα της συνδεσμολογίας μεταξύ των υποσυστημάτων και η ανορθόδοξη χρήση του περιφερειακού απέτρεψε την ομάδα από αυτή την επιλογή.
	\item \textbf{\ac{I2C}}: Ένα επίσης σύγχρονο σειριακό πρωτόκολλο επικοινωνίας. Το πρωτόκολλο χρησιμοποιεί δύο καλώδια για τη μετάδοση δεδομένων μεταξύ δύο κόμβων: SDA (Serial Data) και SCL (Serial Clock) \dualcite{i2c-spec}. Το \ac{I2C} είναι ιδανικό για επικοινωνία μικρών αποστάσεων μεταξύ δύο κόμβων. Το \ac{I2C} υλοποιεί την έννοια της διεύθυνσης για τον κάθε κόμβο στο δίκτυο, όμως η πιο διαδεδομένη χρήση του περιορίζεται στην επικοινωνία συσκευών στην ίδια πλακέτα. Ο λόγος είναι η πιθανή εμφάνιση deadlock, όπου ο δίαυλος \ac{I2C} κολλάει σε κατηλλειμμένη κατάσταση, εμποδίζοντας τον κύριο κόμβο να ξεκινήσει μια νέα συναλλαγή. Αυτό μπορεί να συμβεί όταν μια συσκευή \ac{I2C} slave παρακολουθεί το δίαυλο πριν ο master φέρει τις γραμμές ρολογιού και δεδομένων στη σωστή (παθητική) κατάσταση. Η slave συσκευή πρέπει να παρακολουθεί την κατάσταση των σημάτων ρολογιού και δεδομένων, και ειδικότερα πρέπει να προσέχει για μεταβάσεις οποιουδήποτε σήματος που μπορεί να υποδεικνύουν την έναρξη ή το τέλος μιας συναλλαγής ή την ανάγκη για χρονισμό δεδομένων. Εάν μια slave συσκευή \ac{I2C} παρακολουθεί το δίαυλο πριν ο master φέρει τις γραμμές ρολογιού και δεδομένων στη σωστή (παθητική) κατάσταση, αυτό μπορεί να προκαλέσει το κλείδωμα του διαύλου \ac{I2C} πριν ο master ξεκινήσει την πρώτη συναλλαγή. Για να αποφευχθεί το deadlock, είναι σημαντικό όλες οι συσκευές στο δίαυλο είναι σωστά συγχρονισμένες και να μην υπάρχουν προβλήματα χρονισμού μεταξύ τους. \dualcite{i2clockup}
	\item \textbf{\ac{CAN} Bus}: Ένα πρωτόκολλο που βασίζεται σε μηνύματα και επιτρέπει στους μικροελεγκτές και τις συσκευές να επικοινωνούν μεταξύ τους χωρίς κεντρικό κόμβο. Ο δίαυλος \ac{CAN} χρησιμοποιείται σε πολλές εφαρμογές, συμπεριλαμβανομένων των αυτοκινητοβιομηχανικών, βιομηχανικών και ιατρικών συσκευών. Έχει σχεδιαστεί για να είναι εύρωστο και αξιόπιστο, καθιστώντας το ιδανικό για χρήση σε αυστηρά περιβάλλοντα. Ο δίαυλος \ac{CAN} είναι ένας δίαυλος δύο καλωδίων που χρησιμοποιεί διαφορικά σήματα για τη μετάδοση δεδομένων. Υποστηρίζει υψηλή ταχύτητα δεδομένων και μπορεί να υποστηρίξει πολλαπλές συσκευές στον ίδιο δίαυλο, με αυτόματη διαχείριση συγκρούσεων. 
\end{itemize}

Από αυτά τα πρωτόκολλα επιλέχθηκε το \ac{CAN}, για τρείς βασικούς λόγους. Ο πρώτος λόγος είναι η ισχυρή αξιοπιστία του πρωτοκόλλου, ο δεύτερος είναι η άμεση επικοινωνία των υποσυστημάτων χρησιμοποιώντας ένα κοινό μέσο και ο τρίτος είναι η ισχυρή υποστήριξη του πρωτοκόλλου από τους κατασκευαστές των μικροελεγκτών του δορυφόρου, Microchip και STM.

\section{\ac{CAN} Bus}
\label{canbus}
\subsection{Ιστορία}
Το \acl{CAN} είναι ένα εύρωστο πρωτόκολλο σειριακής επικοινωνίας που αναπτύχθηκε από τη Bosch\dualcite{bosch1991can} τη δεκαετία του 1980 για να παρέχει ένα σύστημα επικοινωνίας χαμηλού κόστους και υψηλής ταχύτητας μεταξύ των ηλεκτρονικών μονάδων ελέγχου (ECU) στα οχήματα. Πλέον είναι ευρέως διαδεδομένο στην αυτοκινητοβιομηχανία και την αεροδιαστημική βιομηχανία, καθώς και στον βιομηχανικό αυτοματισμό και τον ιατρικό εξοπλισμό. Ο δίαυλος \ac{CAN} επιτρέπει σε πολλαπλούς κόμβους να επικοινωνούν μεταξύ τους μέσω ενός μόνο καλωδίου συνεστραμμένου ζεύγους, χρησιμοποιώντας ένα πρωτόκολλο που βασίζεται σε μηνύματα. Είναι γνωστό για τις δυνατότητες ανίχνευσης και διόρθωσης σφαλμάτων, καθιστώντας το ιδανικό για εφαρμογές κρίσιμες για την ασφάλεια.

Ο International Organization for Standardization (ISO) έχει διαδραματίσει σημαντικό ρόλο στην ανάπτυξη και την τυποποίηση του \ac{CAN}. Το 1993, ο ISO κυκλοφόρησε το πρώτο πρότυπο για το \ac{CAN}, γνωστό ως ISO 11898 \dualcite{ISO11898-1:2015}. Αυτό το πρότυπο καθόρισε τα επίπεδα υλικού και ζεύξης δεδομένων του πρωτοκόλλου. Αυτά τα επίπεδα περιλαμβάνουν τον χρονισμό bit, το πλαίσιο μηνυμάτων και το μηχανισμό ανίχνευσης και διόρθωσης σφαλμάτων. Έκτοτε, ο ISO συνέχισε να ενημερώνει και να επεκτείνει το πρότυπο \ac{CAN}, με την πιο πρόσφατη έκδοση να είναι το ISO 11898-1:2015. Αυτά τα πρότυπα έχουν βοηθήσει στη διασφάλιση της διαλειτουργικότητας και της συμβατότητας μεταξύ των διαφορετικών υλοποιήσεων του πρωτοκόλλου \ac{CAN}. Στο πρωτόκολλο του ISO βασίζεται και η υλοποίηση του περιφερειακού \ac{CAN} στον μικροελεγκτή ATMEL SAMV71Q21B που χρησιμοποιείται στον δορυφόρο AcubeSAT \dualcite{datasheet}.

\subsection{Το επίπεδο υλικού}
Το φυσικό μέσο μετάδοσης είναι ένα ζεύγος συνεστραμμένων καλωδίων, με το ένα καλώδιο να μεταφέρει το σήμα \ac{CAN} High (CANH) και το άλλο να μεταφέρει το σήμα \ac{CAN} Low (CANL) σε ένα ισορροπημένο σχήμα διαφορικής σηματοδότησης. Αυτό σημαίνει ότι τα σήματα στα καλώδια CANH και CANL είναι αντίθετα σε πολικότητα μεταξύ τους. Όταν το ένα καλώδιο είναι σε επίπεδο υψηλής τάσης, το άλλο είναι σε επίπεδο χαμηλής τάσης και αντίστροφα. Έτσι, στο δίαυλο δημιουργούνται δύο καταστάσεις, η κυρίαρχη (dominant) και η υποχωρητική (recessive). Στη υποχωρητική κατάσταση, τα σήματα απέχουν \textbf{περισσότερο} από $0.9V$ μεταξύ τους, όμως στην κυρίαρχη απέχουν \textbf{λιγότερο} από $0.5V$.
\begin{figure*}
	\includegraphics[width=0.7\linewidth]{images/can-waveform.png}
	\label{fig:can-waveform}
	\caption[Προβολή κυματομορφών \ac{CAN}]{Προβολή κυματομορφής του διαφορικού ζεύγους σημάτων CANH και CANL. \cite{digikey2021canbus}}
\end{figure*}

Η επικοινωνία στο δίαυλο απαιτεί τη χρήση ενός transceiver σε κάθε κόμβο. Ο transceiver είναι μία συσκευή που προσφέρει μία διεπαφή μεταξύ του περιφερειακού \ac{CAN} που βρίσκεται στο μικροελεγκτή, και το φυσικό δίαυλο. Οι transceivers δέχονται τα μηνύματα προς αποστολή από το περιφερειακό του μικροελεγκτή στην είσοδο TXD και αναλαμβάνουν εξ'ολοκλήρου την αποστολή στο δίαυλο, συμπεριλαμβανομένης και της διαιτησίας που αναφέρεται στην \Cref{subsection:can-usage}.
Κατά τη λήψη ενός μηνύματος, αυτό μεταφέρεται στη γραμμή RXD, όπου το περιφερειακό του μικροελεγκτή θα εκτελέσει τις κατάλληλες ενέργειες για την επεξεργασία του.

Μία τελευταία και σημαντική λεπτομέρεια που αφορά τη φυσική σύνδεση του διαύλου στο \ac{CAN} Bus είναι η χρήση αντιστάσεων τερματισμού. Οι αντιστάσεις τερματισμού είναι απαραίτητες για την αποφυγή ανακλάσεων στο δίαυλο, καθώς και για την επιτάχυνση της απόκρισης του διαύλου.\begin{marginfigure}
	\includegraphics[width=1\linewidth]{diagrams/obc-adcs-transceiver-schematic.pdf}
	\label{fig:transceiver-schematic}
	\caption[Σχηματικό συνδεσμολογίας \ac{CAN} transceiver]{Σχηματικό συνδεσμολογίας \ac{CAN} transceiver στο \ac{OBC}}
\end{marginfigure} Οι αντιστάσεις τερματισμού συνδέονται στις άκρες του διαύλου, όπως φαίνεται στο \Cref{fig:termination-resistors}. Η τιμή των αντιστάσεων τερματισμού εξαρτάται από το μήκος του διαύλου και την ταχύτητα μετάδοσης. 
\marginnote{
	Τα σύμβολα TXD και RXD συμβολίζουν τις γραμμές TX Data και RX Data, αντίστοιχα.
} Στο AcubeSAT, η τιμή των αντιστάσεων τερματισμού είναι $120\Omega$.

\begin{figure*}
	\includegraphics[width=0.7\linewidth]{diagrams/termination-resistors.png}
	\label{fig:termination-resistors}
	\caption[Διάγραμμα διαύλου με τις αντιστάσεις τερματισμού]{Διάγραμμα διαύλου με τις αντιστάσεις τερματισμού. Οι αντιστάσεις τοποθετούνται στα άκρα του διαύλου.}	
\end{figure*}

\subsection{Χρήση}
\label{subsection:can-usage}
Σε ένα συνηθισμένο δίκτυο \ac{CAN}, ανταλλάσονται πολλά σύντομα μηνύματα τα οποία μεταδίδονται σε ολόκληρο το δίκτυο, γεγονός που προσφέρει άμεση μεταφορά δεδομένων σε οποιοδήποτε κόμβο του συστήματος. Ένας κόμβος είναι μια συσκευή που είναι συνδεδεμένη με το δίαυλο \ac{CAN} και μπορεί να μεταδίδει ή να λαμβάνει μηνύματα. Οι κόμβοι συνήθως είναι μικροελεγκτές που εκτελούν συγκεκριμένες λειτουργίες σε ένα πολύπλοκο σύστημα, όπως σε ένα αυτοκίνητο. Ένα μήνυμα στο \ac{CAN} περιέχει μεταδεδομένα που αφορούν τις ρυθμίσεις αποστολής του μηνμύματος, όμως σημαντικότερα, περιλαμβάνει το αναγνωριστικό του αποστολέα, και τα ίδια τα δεδομένα. Υπάρχουν δύο μέθοδοι για τον ορισμό του αναγνωριστικού:

\begin{itemize}
	\item \textbf{Σταθερό αναγνωριστικό ανά αποστολέα}: Όπου όλα τα μηνύματα που προέρχονται από έναν κόμβο φέρουν το ίδιο αναγνωριστικό (άρα και προτεραιότητα) ανεξαρτήτου του περιεχομένου του μηνύματος.
	\item \textbf{Αναγνωριστικό ανάλογο του μηνύματος}: Η μέθοδος αυτή επιτρέπει στον αποστολέα να μεταδώσει μηνύματα με αυξημένη προτεραιότητα, καθώς το αναγνωριστικό αφορά το μήνυμα και όχι τον αποστολέα. Με αυτή τη μορφή τα μηνύματα ύψιστης σημασίας θα φέρουν αναγνωριστικά πιο κοντά στο 0 από ότι τα μηνύματα χαμηλής σημασίας.
\end{itemize}

Κατά τη διάρκεια του σχεδιασμού του AcubeSAT, όπως αναγράφεται στο \Cref{chap:design-choices}, η ομάδα επέλεξε να χρησιμοποιήσει μία υβριδική μορφή. Σε αυτή τη μορφή το αναγνωριστικό του μηνύματος δημιουργείται από την πρόσθεση των αναγνωριστικών μηνύματος και αποστολέα. Αυτό επιτρέπει την αυτόματη ταξινόμηση των μηνυμάτων με βάση την προτεραιότητα, και την ταξινόμηση με βάση τον αποστολέα όταν αυτό είναι απαραίτητο.

Στην πλευρά του παραλήπτη συνήθως ορίζονται φίλτρα στην θύρα εισόδου, έτσι ώστε ο παραλήπτης να ξεχωρίσει τα μηνύματα στα οποία πρέπει να δράσει χωρίς υπολογιστικό κόστος. Το φίλτρο είναι ένας μηχανισμός που επιτρέπει σε έναν κόμβο να δέχεται ή να απορρίπτει μηνύματα με βάση το αναγνωριστικό του αποστολέα.

Ο δίαυλος λειτουργεί σε χρονικές θυρίδες, όπου ο κάθε κόμβος συγχρονίζεται και επιχειρεί να στείλει δεδομένα μόνο στην αρχή μίας χρονικής θυρίδας. Σε περίπτωση που δύο κόμβοι τύχουν να ξεκινήσουν την αποστολή μηνυμάτων στην ίδια χρονική θυρίδα εφαρμόζεται η διαδικασία διαιτησίας. Η διαδικασία διαιτησίας στο δίαυλο \ac{CAN} είναι μια μη καταστρεπτική διαδικασία, όπου κανένα μήνυμα δεν χάνεται. Ο κόμβος που μεταδίδει το μήνυμα με το χαμηλότερο αναγνωριστικό μηνύματος, δηλαδή την υψηλότερη προτεραιότητα, κερδίζει τη διαιτησία και συνεχίζει να εκπέμπει, ενώ οι ανταγωνιστικοί κόμβοι μεταβαίνουν στη λειτουργία λήψης. Οι κόμβοι που έχασαν τη διαιτησία θα ξεκινήσουν μια νέα διαιτησία μόλις ο δίαυλος είναι ελεύθερος για πρόσβαση ξανά.

\begin{figure*}
	\centering
	\includegraphics[width=0.8\linewidth]{diagrams/bus-arbitration.jpg}
	\label{fig:arbitration}
	\caption[Διαδικασία διαιτησίας στο δίαυλο \ac{CAN}]{Διαδικασία διαιτησίας στο δίαυλο \ac{CAN}. Εικόνα από το \cite{comprehensibleguidetocan}}
\end{figure*}

\FloatBarrier

Αναλύοντας το \Cref{fig:arbitration}, στο βέλος με το νούμερο δύο φαίνεται ότι ο κόμβος B \emph{δεν} θέτει το δίαυλο σε dominant (bit = 0) κατάσταση, όμως ο δίαυλος βρίσκεται σε αυτή. Αυτό σημαίνει ότι ο κόμβος B \textbf{δεν έχει} την προτεραιότητα για την αποστολή του μηνύματος και θα πρέπει να περιμένει την επόμενη χρονική θυρίδα.

\subsection{\acs{CAN-FD}}
Το \acl{CAN-FD} είναι μια επέκταση του πρωτοκόλλου \ac{CAN} που επιτρέπει τη μετάδοση μηνυμάτων με μεγαλύτερο μήκος δεδομένων και μεγαλύτερη ταχύτητα μετάδοσης. Το \ac{CAN-FD} επιτρέπει τη μετάδοση μηνυμάτων με μήκος δεδομένων έως και 64 bytes, σε αντίθεση με το κλασικό \ac{CAN} που επιτρέπει μήκος δεδομένων έως και 8 bytes. Επιπλέον, η μέγιστη ταχύτητα μεταφοράς δεδομένων αυξήθηκε από τo 1 MBit/s στα 8 MBit/s.

\marginnote{
	Ακόμα και στην επέκταση \ac{CAN-FD}, η διαδικασία διαιτησίας διατηρεί τη μέγιστη ταχύτητα για την οποία σχεδιάστηκε το κλασικό \ac{CAN}, δηλαδή 1 MBit/s.
}

Η επέκταση δημοσιεύθηκε από τη Bosch το 2012 \dualcite{can_fd_spec}, με σκοπό να καλύψει τις ανάγκες των πλέον πολυπλοκότερων συστημάτων που χρησιμοποιούν \ac{CAN}. Το \ac{CAN-FD} είναι συμβατό με το κλασικό \ac{CAN}, όμως οι κόμβοι που χρησιμοποιούν \ac{CAN-FD} δεν μπορούν να επικοινωνήσουν με κόμβους που χρησιμοποιούν κλασικό \ac{CAN}. Η επέκταση είναι η πλέον διαδεδομένη και χρησιμοποιείται ως βάση σε πολλά συστήματα.

\chapter{Σχεδίαση του νανοδορυφόρου}
\label{chap:design-choices}
Κατά τη διάρκεια της σχεδίασης του νανοδορυφόρου, η ομάδα κλήθηκε να ερευνήσει την εφικτότητα του πλάνου για την επικοινωνία των υποσυστημάτων και να αναπτύξει λεπτομερείς περιγραφές για τον τρόπο με τον οποίο θα επιτευχθεί αυτό. Στην παρούσα ενότητα θα παρουσιαστούν οι αποφάσεις που πάρθηκαν και οι λόγοι που οδήγησαν σε αυτές.

\section{Ορισμός απαιτήσεων συστήματος}
Σε κάθε πρότζεκτ μεγάλης κλίμακας, είναι συνετό να οριστούν οι λεπτομερείς απαιτήσεις του συστήματος στην αρχή της διαδικασίας ανάπτυξης. Οι απαιτήσεις αυτές χρησιμοποιούνται για να ορίσουν τις λειτουργίες του συστήματος, όμως με τη σειρά τους φέρουν στην επιφάνεια αλληλο-εξαρτήσεις μεταξύ υποσυστημάτων, συσκευών κ.α. Επιπλέον, η διαδικασία ορισμού των απαιτήσεων βοηθά στην επιλογή των υλικών και των τεχνολογιών που θα χρησιμοποιηθούν στο σύστημα. Η ομάδα χρησιμοποίησε την τεχνική top-down, όπου ξεκινώντας με τον γενικό σκοπό της αποστολής και εμβαθύνοντας σε πιθανές λύσεις, ανακάλυψε όλες τις λεπτομέρειες που απαιτούνται για τη λειτουργία του συστήματος. Οι απαιτήσεις ορίστηκαν σε ένα φύλλο Excel και ακολουθώντας τον Open-Source χαρακτήρα της ομάδας, είναι δημοσίως διαθέσιμες στο έγγραφο \textbf{TS-VCD} \dualcite{TSVCD}.

Κάθε απαίτηση περιλαμβάνει δύο πεδία. Αρχικά, το αναγνωριστικό περιλαμβάνει το υποσύστημα στο οποίο αναφέρεται η απαίτηση, τον τύπο (Λειτουργική, Φυσική, Σχεδιαστική) και έναν αύξοντα αριθμό που κάνει το κάθε αναγνωριστικό μοναδικό. Επιπλέον, κάθε απαίτηση περιλαμβάνει μία σύντομη περιγραφή. Η περιγραφή αυτή αναφέρει το επιθυμητό αποτέλεσμα και όχι τον τρόπο με τον οποίο θα επιτευχθεί.

Όπως αναφέρεται στο έγγραφο \dualcite{ECSS-E-ST-10-06C} μερικές από τις πιθανές κατηγορίες των απαιτήσεων είναι:
\begin{itemize}
	\item \textbf{Λειτουργικές}: Αναφέρονται σε λειτουργίες του συστήματος (π.χ. Ο δορυφόρος πρέπει να διατηρεί την ένδειξη της ώρας με ακρίβεια 10ms)
	\item \textbf{Φυσικές}: Αναφέρονται σε φυσικά χαρακτηριστικά του συστήματος (π.χ. Η συνολική μάζα του δορυφόρου δεν πρέπει να ξεπερνά τα 8 χιλιογραμμάρια)
	\item \textbf{Σχεδιαστικές}: Ορίζουν τα πρότυπα σχεδιασμού, τον κατάλογο επιλογής εξαρτημάτων κ.α. (π.χ. Οι διαστάσεις των πλακετών του δορυφόρου πρέπει να ακολουθούν τις ενδείξεις του LibreCube Board Specification)
\end{itemize}

\begin{table*}
	\centering
	\caption[Παράδειγμα απαιτήσεων του AcubeSAT]{Παράδειγμα απαιτήσεων του AcubeSAT}
	\label{tab:requirements}
	\begin{tabular}{|
		>{\columncolor[HTML]{F0F0F1}}c 
		>{\columncolor[HTML]{F0F0F1}}c |}
		\cline{1-2}
		\hline
		\multicolumn{2}{|c|}{\cellcolor[HTML]{4F5054}{\color[HTML]{FFFFFF} Requirements}}                                                                                                                                                                          \\ \hline
		\multicolumn{1}{|c|}{\cellcolor[HTML]{F0F0F1}{OBC-FUN-090}} & {The \ac{OBC} shall be able to reprogram all on-board MCUs while in orbit.}                                                                                                         \\ \hline
		\multicolumn{1}{|c|}{\cellcolor[HTML]{F0F0F1}{SYS-FUN-270}} & {\begin{tabular}[c]{@{}c@{}}All on-board MCUs shall be capable of remote reprogramming via \acs{TC} in orbit\\ for all parts of the software excluding the bootloader.\end{tabular}} \\ \hline
	\end{tabular}
\end{table*}

Ένα παράδειγμα από τις απαιτήσεις του AcubeSAT φαίνεται στον \Cref{tab:requirements}.

\section{Λειτουργία δύο ανεξάρτητων διαύλων}
\marginnote{
	Η \href{https://librecube.org/}{αρχική σελίδα} της LibreCube
}
Η ομάδα βασιζόμενη στην Open Source φιλοσοφία της, επέλεξε να ακολουθήσει της οδηγίες που αφορούν την συνδεσιμότητα υποσυστημάτων σε νανοδορυφόρους με βάση το SpaceCAN \dualcite{SpaceCAN}. Οι οδηγίες αυτές παρέχονται από την \texttt{LibreCube}, με σκοπό την τυποποίηση του σχεδιασμού και των λειτουργιών των CubeSats. Η τυποποίηση έχει συνδράμει σημαντικό ρόλο στη μείωση κόστους στις αποστολές, στην ενίχυση της συμβατότητας υποσυστημάτων και στην βελτίωση της αξιοπιστίας των συστημάτων. Η ομάδα ακολούθησε τις οδηγίες για την τοπολογία του υλικού και την αρχιτεκτονική του διαύλου.

Παρ'ότι το πρωτοκόλλο είναι σχεδιασμένο και φημίζεται για την ανοχή του σε σφάλματα, η λειτουργία του διαύλου επικοινωνίας είναι ύψιστης σημασίας για την ασφάλεια του δορυφόρου. Στα πλαίσια του συστήματος Εντοπισμού, Αναγνώρισης και Επιδιόρθωσης Σφαλμάτων (\acs{FDIR}), η ομάδα αποφάσισε να συμπεριλάβει ένα δεύτερο δίαυλο \ac{CAN} Bus σε διαμόρφωση ψυχρού πλεονασμού, όπως αναγράφεται από το SpaceCAN \dualcite{SpaceCAN} στάνταρ. Ο δίαυλος συστήματος είναι ανθεκτικός σε αστοχία ενός σημείου (Single Point of Failure) (όπως πρόβλημα στην καλωδίωση ή σφάλμα σύνδεσης) μέσω πλεονάζουσας τοπολογίας φυσικών μέσων. 

Φυσικά, τα πλεονάζοντα κανάλια επικοινωνίας απαιτούν ένα σύστημα διαχείρισης πλεονασμάτων. Το επιλεγμένο σχήμα για ψυχρό πλεονασμό (δηλαδή, ένας δίαυλος ενεργός ανά πάσα χρονική στιγμή) εφαρμόζει την έννοια της παρακολούθησης κόμβων μέσω καρδιακών παλμών. Σε αυτό το σχήμα, όλα τα υποσυστήματα στέλνουν περιοδικά μηνύματα καρδιακού παλμού, τα οποία εξ'ορισμού δεν περιλαμβάνουν πεδίο δεδομένων. Σε κάθε λήψη, το \ac{OBC} ανανεώνει τη λίστα με την τελευταία επιτυχή επικοινωνία από κάθε υποσύστημα. Εάν δεν ληφθεί ένα μήνυμα καρδιακού παλμού σε διάστημα 30 δευτερολέπτων, θεωρείται ότι υπάρχει βλάβη. Σε περίπτωση βλάβης επικοινωνίας θεωρείται ότι ο δίαυλος απέτυχε, είτε για ένα μόνο υποσύστημα είτε για ολόκληρο το δίκτυο. Το \ac{OBC} μπορεί στη συνέχεια να μεταδώσει ένα μήνυμα και στους δύο διαύλους (οι οποίοι παρακολουθούνται ήδη παθητικά από όλους τους μικροελεγκτές), για να διασφαλιστεί η άμεση μετάβαση στον πλεονάζοντα δίαυλο. Μετά τη μετάβαση, το \ac{OBC} αποφασίζει εάν ο δίαυλος ήταν προβληματικός ή αν κάποιο υποσύστημα εξακολουθεί να αντιμετωπίζει προβλήματα και χρειάζεται περαιτέρω διενέργεια επιδιόρθωσης σφαλμάτων \dualcite{FMEA}.

\begin{figure}[h]
	\includegraphics[width=0.8\linewidth]{media/diagrams/subsystems-on-buses.pdf}
	\label{fig:dual-buses}
	\caption[Συνδεσμολογία των υποσυστημάτων στους διαύλους]{Συνδεσμολογία των υποσυστημάτων στο κύριο και εφεδρικό διαύλο. Διάγραμμα από το \cite{DDJF_OBDH}}
\end{figure}

\section{Ορισμός AcubeSAT specific πρωτοκόλλου \ac{CAN}}
Η δεύτερη επιλογή που αντιμετώπισε η ομάδα είναι της μορφής των μηνυμάτων που θα μεταφέρονται μέσω του \ac{CAN}. Αποφασίστηκε ότι αυτά τα μηνύματα θα ακολουθούν πρωτόκολλο επιπέδου Application Layer (OSI Layer 7). Η ομάδα αρχικά εξέτασε επιλογές που είναι ήδη εδραιωμένες στον τομέα, όπως το SpaceCAN, το CANOpen ή το ECSS-E-ST-50-15C \dualcite{ECSS-E-ST-50-15C}. Τα παραπάνω πρωτόκολλα δεν ικανοποιούν τις απαιτήσεις της αποστολής για χαμηλή πολυπλοκότητα. Επιπλέον, εφ'όσον αυτή τη στιγμή ακόμα δεν υπάρχει πρότυπο για πρωτόκολλο σε CubeSat, η ομάδα αποφάσισε να σχεδιάσει ένα νέο πρωτόκολλο, με βάση το SpaceCAN, το οποίο θα καλύπτει τις ανάγκες της αποστολής.

Οι λεπτομέρειες του πρωτοκόλλου φαίνονται στο παράρτημα Α του \dualcite{DDJF_OBDH}. Για ευκολία στον αναγνώστη, παρακάτω εμφανίζεται ένα διάγραμμα που περιγράφει την αρχιτεκτονική ενός μηνύματος.

\begin{figure*}[h]
	\includegraphics[width=0.6\linewidth]{media/diagrams/tp-message-structure.pdf}
	\label{fig:tp-message-structure}
	\caption[Αρχιτεκτονική ενός μηνύματος τύπου \ac{CAN-TP}.]{Διάγραμμα που περιγράφει την αρχιτεκτονική ενός μηνύματος τύπου \ac{CAN-TP}. Το πεδίο δεδομένων δεν περιορίζεται στα 64-byte ενός μηνύματος \ac{CAN}, αλλά μπορεί να είναι μέχρι 1023-byte.}
\end{figure*}
\FloatBarrier

Όπως αναφέρθηκε παραπάνω, το πρωτόκολλο λειτουργεί με την χρήση χρονικών θυρίδων για την μεταφορά μηνυμάτων. Η διαδικασία διαιτησίας του \ac{CAN} μας δίνει την δυνατότητα να ορίσουμε προτεραιότητες στα μηνύματα. Η ομάδα αξιοποίησε αυτή τη λειτουργία, 
\begin{marginfigure}
	\includegraphics[width=0.9\linewidth]{media/diagrams/heartbeat-message.pdf}
	\label{fig:heartbeat-message}
	\caption[Αρχιτεκτονική μηνύματος καρδιακού παλμού]{Αρχιτεκτονική μηνύματος καρδιακού παλμού. Το αναγνωριστικό του μηνύματος είναι το άθροισμα του δεκαεξαδικού αριθμού \texttt{0x700} και του αναγνωριστικού του υποσυστήματος.}
\end{marginfigure}\FloatBarrier όταν όρισε το σχήμα των μηνυμάτων. Το αναγνωριστικό κάθε μηνύματος περιέχει τον τύπο του, σε συνδυασμό με το αναγνωριστικό του αποστολέα. Με αυτό τον τρόπο είναι δυνατή η αυτόματη ταξινόμηση των μηνυμάτων με βάση προτεραιότητας. Για παράδειγμα, ένα μήνυμα που συγχρονίζει την ώρα στα υποσυστήματα πρέπει να μεταφερθεί με μεγάλη προτεραιότητα ώστε να εκτελεστεί πιο γρήγορα σε σχέση με ένα μήνυμα \textit{καρδιακού παλμού}.

Ο παραπάνω συνδυασμός αναγνωριστικών ορίζει την προτεραιότητα των υποσυστημάτων στο δίαυλο. Όπως φαίνεται στον  \Cref{tab:subsystem-ids}, το υποσύστημα του \ac{OBC} έχει την μεγαλύτερη προτεραιότητα στον δίαυλο. Στην συνέχεια, προτεραιότητα έχουν τα υποσυστήματα του \ac{COMMS}, \ac{SU} και \ac{ADCS}, με την σειρά που αναφέρθηκαν. Η σειρά επιλέχθηκε καθώς το \ac{OBC} είναι υπεύθυνο για τις διαδικασίες αποσφαλμάτωσης του δορυφόρου, οι οποίες αποτελούν ύψιστης σημασίας για την εξασφάλιση της αποστολής. Στη συνέχεια, καθώς το \ac{COMMS} μεταφέρει τηλε-εντολές από τον σταθμό βάσης, αρμόζει στην δεύτερη μεγαλύτερη προτεραιότητα στο δίαυλο. Το υποσύστημα του \ac{SU} φέρει την τρίτη μεγαλύτερη προτεραιότητα στο δίαυλο, καθώς η μεταφορά των εικόνων στο \ac{COMMS} για αποστολή στο σταθμό βάσης, κρίθηκε σημαντικότερη από τα δεδομένα των αισθητήρων του \ac{ADCS}.

\begin{table}
	\centering
	\definecolor{Alto}{rgb}{0.815,0.815,0.815}
	\definecolor{WildSand}{rgb}{0.956,0.956,0.956}
	\begin{tblr}{
	  cells = {c},
	  row{odd} = {WildSand},
	  row{1} = {Alto},
	  vlines,
	  vline{2} = {1}{0.05em},
	  hline{1,6} = {-}{0.08em},
	  hline{2} = {-}{},
	}
	\textbf{Address} & \textbf{Subsystem} \\
	0x0              & OBC                \\
	0x1              & COMMS              \\
	0x2              & SU                 \\
	0x3              & ADCS               
	\end{tblr}
	\label{tab:subsystem-ids}
	\caption[Πίνακας αναγνωριστικών υποσυστημάτων]{Πίνακας αναγνωριστικών υποσυστημάτων}
\end{table}


\chapter{Υλοποίηση}
\label{chap:implementation}
\section{Περιβάλλον Υλοποίησης}
\label{sec:environment}
\marginnote{
	Ο bootloader είναι το πρώτο κομμάτι κώδικα που εκτελείται από το μικροελεγκτή κατά την εκκίνησή του. Ο κώδικας είναι υπεύθυνος για την λήψη λογισμικού και την επιλογή διαμερίσματος μνήμης. Τέλος, είναι υπέυθυνος για την αναγνώριση σφαλμάτων στην εκκίνηση του λογισμικού και την εκτέλεση διαδικασιών αποκατάστασης του συστήματος.
}

Η ομάδα αποφάσισε ότι οι γλώσσες που θα χρησιμοποιηθούν για το λογισμικό που θα εκτελεστεί στο δορυφόρο να είναι μία μίξη των C, C++ και Assembly, όπως αναφέρεται στην απαίτηση συστήματος του \Cref{tab:language-requirements}. Η C++ είναι μια αντικειμενοστραφής γλώσσα που επιτρέπει τον απαραίτητο χαμηλού επιπέδου χειρισμό μνήμης από τις δομές δεδομένων που χρησιμοποιούνται. Ταυτόχρονα, η γλώσσα C χρησιμοποιείται σε κώδικα κρίσιμο για την αποστολή, όπως ο bootloader και μερικά βασικά προγράμματα οδήγησης, καθώς οι λειτουργίες αυτές είναι αυστηρά ορισμένες από τον κατασκευαστή του μικροελεγκτή.

\begin{table*}
    \centering
    \caption{Απαιτήσεις σχετικά με τις γλώσσες προγραμματισμού στο δορυφόρο}
    \label{tab:language-requirements}
    \begin{tabular}{|p{0.45\linewidth}|p{0.45\linewidth}|}
        \hline
        \rowcolor[HTML]{4F5054}
        \multicolumn{2}{|c|}{\color[HTML]{FFFFFF} Requirements} \\ \hline
        \rowcolor[HTML]{F0F0F1} SW-DES-060 & The programming languages used for all on-board software shall be Assembly, C and C++. \\ \hline
    \end{tabular}
\end{table*}

Κατά τη διάρκεια της υλοποίησης του λογισμικού του δορυφόρου, η ομάδα κλήθηκε να υλοποιήσει το στάνταρ \emph{ECSS-E-ST-70-41C}\dualcite{ECSS-E-ST-70-41C}, με τίτλο \textbf{Telemetry and telecommand packet utilization}. Όπως αναφέρεται στα έγγραφα \emph{DDJF\_OBSW} \dualcite{DDJF_OBSW} και \emph{DDJF\_OBDH} \dualcite{DDJF_OBDH}, η ομάδα χρησιμοποιεί ένα υποσύνολο των υπηρεσιών που περιγράφονται από το στάνταρ, σύμφωνα με τις απαιτήσεις του συστήματος που θα χρησιμοποιήσει τις υπηρεσίες κατά τη διάρκεια της αποστολής. Η υλοποίηση των \ac{ECSS} Services από την ομάδα βρίσκεται στο GitLab της ομάδας. \marginnote{
	Σύνδεσμος για το αποθετήριο \href{https://gitlab.com/acubesat/obc/ecss-services}{ecss-services}
} Ο κώδικας είναι γραμμένος σε C++17, τηρεί τις προδιαγραφές της ομάδας σε στύλ κώδικα, τους περιορισμούς που αναφέρονται παρακάτω και υπόκειται σε αυστηρό peer-review.

\marginnote{
	Ο κώδικας που υλοποιεί τα \ac{ECSS} Services είναι τόσο στενά συνδεδεμένος με το υπόλοιπο λογισμικό του δορυφόρου, ώστε να αποτελέσει θεμέλιο για τον κώδικα που εξυπηρετεί τα ανώτερα επίπεδα του \ac{CAN} Bus. 
}

\par Η ομάδα από το στάδιο σχεδίασης του λογισμικού του δορυφόρου αποφάσισε να βασιστεί στο FreeRTOS. Είναι ένα δωρεάν και ανοικτού κώδικα λειτουργικό σύστημα για μικροελεγκτές, το οποίο υποστηρίζει πλήθος λειτουργιών που συνδράμουν ιδιαίτερα στην ταχεία ανάπτυξη περίπλοκων συστημάτων. Πρόκειται για ένα λειτουργικό σύστημα πραγματικού χρόνου. Τα λειτουργικά συστήματα πραγματικού χρόνου τηρούν αυστηρές προδιαγραφές ως προς το χρόνο που εκτελούνται οι διεργασίες, όπου ο χρόνος αυτός συνήθως μετράται σε χιλιοστά του δευτερολέπτου. Το λειτουργικό σύστημα χρησιμοποιεί την έννοια της διεργασίας (Task) για την εκτέλεση πολλαπλών εργασιών. \marginnote{ \href{https://www.freertos.org/index.html}{Η αρχική σελίδα του FreeRTOS}} Ένα FreeRTOS Task παίρνει την μορφή μίας συνάρτησης σε C, και εκτελείται εις αεί, χρησιμοποιώντας μία συνθήκη \mintinline{c++}|while(true)|. Ο χρήστης ορίζει τη συμπερφιορά του συστήματος όσον αφορά την είσοδο στη διεργασία, χρησιμοποιώντας χρονική καθυστέρηση, ειδοποιήσεις ή ουρές μηνυμάτων. Οι λειτουργίες αυτές χρησιμοποιούνται στο λογισμικό του δορυφόρου και ειδικότερα στα κομμάτια που συνδέουν την λειτουργικότητα του \ac{CAN} Bus με το λειτουργικό σύστημα, και θα αναλυθούν με περισσότερη λεπτομέρεια στις επόμενες ενότητες. Η χρήση ενός λειτουργικού συστήματος με αυτή τη δυνατότητα μας δίνει την επιλογή να εκτελέσουμε πολλαπλές διεργασίες ψευδό-παράλληλα, σε ενσωματωμένα συστήματατα που διαθέτουν ένα μόνο επεξεργαστικό πυρήνα. Το λειτουργικό σύστημα είναι υπεύθυνο για τη διαχείριση της μνήμης, όσον αφορά τις ανάγκες κάθε διεργασίας.

Οι διεργασίες εκτελούνται χρησιμοποιώντας \textbf{προληπτικό προγραμματισμό με διαχωρισμό στο χρόνο}. Ο διαχωρισμός στο χρόνο χρησιμοποιείται για την κατανομή του χρόνου επεξεργασίας μεταξύ εργασιών προσημασμένες με ίση προτεραιότητα, ακόμη και όταν οι εργασίες δεν παύουν τη λειτουργία τους ρητά ή δεν εισέρχονται στην κατάσταση αποκλεισμού (blocked). Οι αλγόριθμοι προγραμματισμού που χρησιμοποιούν το «Time Slicing» θα επιλέξουν μια νέα εργασία για να εισαχθεί στην κατάσταση εκτέλεσης, μόνο εάν υπάρχουν άλλες διεργασίες σε κατάσταση ετοιμότητας, που έχουν την ίδια ή μεγαλύτερη προτεραιότητα με την διεργασία που βρίσκεται ήδη στη κατάσταση εκτέλεσης. \marginnote{Ο ελάχιστη διαβάθμιση του χρόνου στο FreeRTOS λέγεται tick, από τον χτύπο του ρολογιού}Η μικρότερη μονάδα χρόνου στη διαδικασία προληπτικού προγραμματισμού με διαχωρισμό στο χρόνο είναι ίση με το χρόνο μεταξύ δύο χτύπων ρολογιού στο FreeRTOS.

\begin{figure}[ht]
	\includegraphics[width=1\linewidth]{media/diagrams/freeRTOS-preemptive-multitasking.png}
	\caption[Συμπερφιορά pre-emptive multitasking στο FreeRTOS]{Συμπερφιορά pre-emptive multitasking στο FreeRTOS. Εικόνα από \cite{FreeRTOSManual}}
	\label{fig:freeRTOS-preemptive-multitasking}
\end{figure}

Το λειτουργικό σύστημα FreeRTOS παρέχει μηχανισμούς μεταφοράς δεδομένων που αρμόζουν στις ανάγκες της αποστολής. Ένας από αυτούς τους μηχανισμούς, ο οποίος φαίνεται εξαιρετικά σημαντικός για την υλοποίηση του \ac{CAN} Bus είναι η ουρά. Η ουρά προσφέρει τη δυνατότητα μεταφοράς δεδομένων με τρόπο \ac{FIFO} μεταξύ διεργασιών, αλλά και από \ac{ISR} σε διεργασίες. Οι ουρές μπορούν να δημιουργηθούν χρησιμοποιώντας στατική εκχώρηση μνήμης, όπως απαιτείται από τις ανάγκες της αποστολής. Οι εντολές που χρησιμοποιούνται για την δημιουργία μίας ουράς χρησιμοποιώντας στατική εκχώρηση μνήμης στο FreeRTOS φαίνονται στο \Cref{lst:gatekeeper-queue}.

\begin{figure*}[h]
	\inputminted{c++}{code/examples/gatekeeper-queue.cpp}
	\label{lst:gatekeeper-queue}
	\caption[Δημιουργία στατικών ουρών στο FreeRTOS]{Δημιουργία στατικών ουρών στο FreeRTOS}
\end{figure*}
\FloatBarrier
\label{sec:queue-registry}
Μία ενδιαφέρουσα παρατήρηση είναι η εντολή \mintinline{c++}{vQueueAddToRegistry()} που φαίνεται στη γραμμή 21. Η εντολή αυτή χρησιμοποιείται για να διευκολύνει τις διαδικασίες αποσφαλμάτωσης του κώδικα. Με την χρήση αυτής, το πρόγραμμα αποσφαλμάτωσης μπορεί πλέον να αναγνωρίσει την ύπαρξη ουράς και να εμφανίσει τα δεδομένα της με ευανάγνωστο τρόπο στο γραφικό περιβάλλον αποσφαλμάτωσης. Η παρούσα λειτουργία του FreeRTOS συνδυάζεται με την \emph{ενσωμάτωση \acs{RTOS}} από το \emph{CLion}, το οποίο πρόγραμμα χρησιμοποιείται από την ομάδα για την ανάπτυξη του λογισμικού του δορυφόρου. Όπως φαίνεται στο \Cref{fig:clion-queues}, τα δεδομένα του λειτουργικού συστήματος εμφανίζονται με ευανάγνωστο τρόπο και παρέχεται εύκολη προβολή στα δεδομένα της ουράς στη μνήμη. 

Το επόμενο βήμα στη χρήση της ουράς είναι ο ορισμός του παραλήπτη στην έξοδο της ουράς. Για αυτό το σκοπό, στην περίπτωση της ουράς του παραδείγματος, χρησιμοποιείται το CANGatekeeperTask. Η διαδικασία επεξεργασίας δεδομένων από την ουρά είναι πολύ απλή χάρη στο FreeRTOS. Στο παράδειγμα του \Cref{code:gatekeeper-execute-short}, η διεργασία CANGatekeeperTask θα εισέλθει στην κατάσταση \texttt{blocked} στη γραμμή 3, έως ότου επιλεχθεί η σειρά της διεργασίας στον αλγόριθμο χρονοπρογραμματισμού (scheduler), ενώ ταυτόχρονα αναμένει ένα αντικείμενο στην ουρά.
\begin{figure*}
	\inputminted{c++}{code/examples/gatekeeper-execute-short.cpp}
	\label{code:gatekeeper-execute-short}
	\caption[Λήψη μηνυμάτων από την ουρά του FreeRTOS]{Λήψη μηνυμάτων από την ουρά του FreeRTOS}
\end{figure*}

Ένα σημείο που χρήζει ιδιαίτερη προσοχή στο σύστημα που παρέχεται από το FreeRTOS είναι η χρήση C-pointer στις συναρτήσεις της ουράς. Όπως φαίνεται στον κώδικα, στη συνάρτηση \mintinline{c++}|xQueueReceive()|, παρέχεται η διεύθυνση μνήμης για ένα αντικείμενο στο οποίο θα αποθηκευτούν τα δεδομένα της ουράς. Η χρήση της γλώσσας C για την υλοποίηση του FreeRTOS δεν παρέχει τις ίδιες δυνατότητες με την C++ για παραμετροποίηση συναρτήσεων με τη χρήση προτύπων (templates). Η εντολή δέχεται μόλις τη διεύθυνση μνήμης για το αντικείμενο που πρόκειται να στείλουμε, αγνοώντας διαδικασίες εξαφσάλισης strict-aliasing. Το φαινόμενο strict-aliasing αφορά τις γλώσσες προγραμματισμού με διαχείριση μνήμης από τον προγραμματιστή και αναφέρεται στη περίπτωση όπου ένα σημείο μνήμης μπορεί να προσπελαστεί από δύο διαφορετικούς pointers με διαφορετικούς τύπους. Σε αυτή τη περίπτωση παραβιάζεται ο κανόνας strict-aliasing και το πρόγραμμα οδηγείται σε απροσδιόριστη συμπεριφορά. Ως αποτέλεσμα, ο προγραμματιστής πρέπει να είναι ιδιαίτερα προσεκτικός ώστε ο τύπος δεδομένων που αποθηκεύεται στη μνήμη του ορίσματος να είναι ίδιος με τον τύπο δεδομένων της ουράς. Στην παρούσα περίπτωση μεταφέρονται ολόκληρα αντικείμενα της κλάσης \mintinline{c++}|CAN::Frame|, δηλαδή κάποιο παρόμοιο λάθος θα ήταν εύκολα εμφανές, όμως είναι πολύ εύκολο να γίνει λάθος μεταξύ τύπων προσημασμένων και μη-προσημασμένων αριθμών, οδηγώντας σε λανθασμένη συμπεριφορά.

Το τελικό βήμα για τη χρήση μίας ουράς είναι η αποστολή δεδομένων μέσα από αυτή. Για την διαδικασία αυτή χρησιμοποιείται μία μόλις εντολή, η \mintinline{c++}|xQueueSendToBack(outgoingQueue, &message, 0)|. Η εντολή αυτή επίσης ενέχει τον κίνδυνο που αναφέρθηκε παραπάνω, και ο προγραμματιστής πρέπει να είναι ιδιαίτερα προσεκτικός όσον αφορά τον τύπο δεδομένων που συναλλάσσει με την ουρά. 

Η παρούσα εργασία έγινε όσο ήμουν μέλος του υποσυστήματος \ac{OBC}, από το εαρινό εξαμήνο του έτους 2022, έως το εαρινό εξάμηνο του 2023. Καθώς η ομάδα ήταν στο στάδιο σχεδίασης της πλακέτας που στεγάζει τα υποσυστήματα των \ac{OBC} και \ac{ADCS}, η ανάπτυξη έγινε σε δύο πλακέτες \textbf{SAM V71 XPLAINED ULTRA EVALUATION KIT}, οι οποίες στο πλαίσιο αυτής της εργασίας θα αναφέρονται ως \textbf{Xplained Ultra}, ή \textbf{Development Boards}. Οι πλακέτες αυτές παράγονται από την Microchip και περιέχουν τον ίδιο μικροελεγκτή που θα χρησιμοποιηθεί σε τρία από τα υποσυστήματα του νανοδορυφόρου. Η επιλογή αυτή έγινε για να επιταχυνθεί η ανάπτυξη του λογισμικού, καθώς η πλακέτα περιέχει τον απαραίτητο transceiver για την λειτουργία του \ac{CAN} Bus. 

\begin{figure}
	\centering
	\includegraphics[width=0.6\linewidth]{images/xplained-ultra.png}
	\label{fig:xplained-ultra}
	\caption[Απεικόνιση της πλακέτας SAM V71 XPLAINED ULTRA EVALUATION KIT]{Απεικόνιση της πλακέτας SAM V71 XPLAINED ULTRA EVALUATION KIT}
\end{figure}

Όπως αναφέρθηκε στην παραπάνω ενότητα, για την επικοινωνία στο δίαυλο απαιτούνται δύο συνδέσεις, CANH και CANL. Το πρωτόκολλο \ac{CAN} δεν απαιτεί την χρήση αντιστάσεων τερματισμού, όμως η χρήση τους είναι σημαντική για την αποφυγή ανακλάσεων στο σήμα. Στην παρούσα περίπτωση, μπορούμε να \textbf{αποφύγουμε} τη χρήση αντιστάσεων τερματισμού με την χρήση καλωδίων παράλληλης ζεύξης μικρού μήκους, όπως φαίνεται στο \Cref{fig:lab-wiring-closeup}.

\begin{figure}
	\includegraphics[angle=180,origin=c,width=1\linewidth]{images/lab-wiring-closeup.jpg}
	\label{fig:lab-wiring-closeup}
	\caption[Συνδεσμολογία Development Board σε Breadboard]{Συνδεσμολογία Development Board σε Breadboard}
\end{figure}

Το σύνολο της εργασίας μου έγινε υπό άδεια MIT, \marginnote{
	Το πλήρες περιεχόμενο της \href{https://opensource.org/license/mit/}{άδειας MIT}
} όπως λειτουργεί και το υπόλοιπο project του λογισμικού του δορυφόρου. Η άδεια αυτή επιτρέπει την οποιαδήποτε χρήση του λογισμικού, χωρίς άδεια από τον δημιουργό. Ο δημιουργός δεν παρέχει καμία εγγύηση, αλλά και καμία υποχρέωση καλής λειτουργίας του λογισμικού. 

\marginnote{
	Σύνδεσμος για το \href{https://gitlab.com/acubesat/obc/obc-software/-/merge_requests/21}{Merge Request που προστέθηκε η βασική λειτουργία του \ac{CAN} Bus}

	Σύνδεσμος για το \href{https://gitlab.com/acubesat/obc/obc-software/-/merge_requests/55}{Merge Request που επεκτάθηκε η υλοποίηση με τα υπόλοιπα επίπεδα λογισμικού}
}
Κατά τη διάρκεια της ανάπτυξης του λογισμικού η δουλειά μου καταγράφθηκε χρησιμοποιώντας το Git για Version Control στα αποθετήρια της ομάδας. Οι σύνδεσμοι οδηγούν στα σχετικά Merge Requests που έγιναν στο GitLab της ομάδας. Εκεί φαίνεται ο χαρακτήρας της ομάδας, όσο αφορά το peer-review. Όλες οι αλλαγές που έγιναν στον κώδικα ελέγχθηκαν από τουλάχιστον δύο συμφοιτητές, έγιναν περισσότερα από 200 σχόλια και επισημάνσεις στον κώδικα προτού ενσωματωθούν στον κώδικα του δορυφόρου \dualcite{SWRS}.

\clearpage
\section{Περιορισμοί συστήματος}

\begin{marginfigure}
	\centering
	\includegraphics[width=0.9\linewidth]{images/SAMV71Q21RT.png}
	\label{fig:samv71-rad-mcu}
	\caption[Το ανεκτικό στη ακτινοβολία πακέτο του μικροελεγκτή SAMV71Q21B της Microchip]{Το ανεκτικό στη ακτινοβολία πακέτο του μικροελεγκτή SAMV71Q21B της Microchip}
\end{marginfigure}

\marginnote{
	Σύνδεσμος για το \href{https://ww1.microchip.com/downloads/en/DeviceDoc/30009904V.pdf}{32-bit Microcontrollers Brochure}
}
Κατά τη διάρκεια της διαδικασίας σχεδίασης του δορυφόρου, η ομάδα κλήθηκε να επιλέξει τους μικρoελεγκτές που θα στεγάζουν τα υποσυστήματα του δορυφόρου. Κατέληξε στη χρήση του μικροελεγκτή ATMEL SAMV71Q21B για όλα τα υποσυστήματα που θα αναπτυχθούν εξ'ολοκλήρου από την ομάδα, που όπως αναφέρθηκε παραπάνω είναι τα \ac{OBC}, \ac{ADCS} και \ac{SU}. Η απόφαση αυτή πρωτίστως βασίζεται στην ικανότητα του μικροελεγκτή να καλύψει τις ανάγκες της αποστολής, τόσο από άποψη επεξεργαστικής ισχύος αλλά και από άποψη μνήμης. Ο μικροελεγκτής ATMEL SAMV71Q21B βρίσκεται στην οικογένεια των 32-bit μικροελεγκτών της Microchip, και συγκεκριμένα στην οικογένεια SAMV. Όπως φαίνεται στην σελίδα 3 του φυλλαδίου επιλογής μικροελεγκτή από την Microchip, οι μικροελεγκτές της σειράς SAMV ταιριάζουν περισσότερο σε αυτοκινητιστικές εφαρμογές αλλά και εφαρμογές βιομηχανικού αυτοματισμού. Οι εφαρμογές αυτές έχουν πολύ υψηλές προδιαγραφές ασφάλειας και ορθής λειτουργίας, και ο μικροελεγκτής προσφέρει πληθώρα λειτουργιών με σκοπό να καλύψει αυτές. Αυτές οι λειτουργίες είναι εξαιρετικά χρήσιμες στις διαδικασίες εντοπισμού, αναγνώρισης και αποσφαλμάτωσης προβλημάτων στο νανοδορυφόρο και βοήθησαν στην επιλογή της συγκεκριμένης οικογένειας μικροελεγκτών.

\begin{figure*}[hb]
	\includegraphics[width=1\linewidth]{media/diagrams/obc-mcu-schematic.pdf}
	\label{diag:obc-mcu-schematic}
	\caption{Προβολή του μικροελεγκτή του \ac{OBC}, από το σχηματικό του \ac{OBC}/\ac{ADCS} Board}
\end{figure*}

Ένα επίσης σημαντικό κριτήριο επιλογής ενός μικροελεγκτή είναι η διαθεσιμότητα περιφερειακών και ο αριθμός των επαφών (pins). Όπως φαίνεται στο \Cref{diag:obc-mcu-schematic} από το σχηματικό του \ac{OBC}/\ac{ADCS} Board, ο μικροελεγκτής του \ac{OBC} έχει μόλις 28 επαφές οι οποίες δεν χρησιμοποιούνται, από τις 144 διαθέσιμες. Επιπλέον, χρησιμοποιούνται δυνατότητες όπως δύο ανεξάρτητα περιφερειακά για τους δύο διαύλους του \ac{CAN} Bus, ένας Watchdog Timer που χρησιμοποιείται για την αποκατάσταση του μικροελεγκτή σε περίπτωση που αυτός δεν αποκρίνεται, αλλά και διεπαφές για εξωτερικές μνήμες όπως \ac{NAND} για τα \ac{OBC}, \ac{SU} και \ac{MRAM} για το \ac{OBC}.

\clearpage

\marginnote{
	Χρησιμοποιώντας αποκλειστικά στατικά εκχωρημένη μνήμη, απαγορεύεται η χρήση της συνάρτησης \mintinline{c++}|malloc|, και ως αποτέλεσμα η χρήση της σωρού (heap). Χρησιμοποιούνται αποκλειστικά εκχωρήσεις στη στοίβα για τοπικές μεταβλητές, γεγονός που πρέπει να δώσει έμφαση ο προγραμματιστής όταν μεταφέρει δείκτες (pointers) μέσα από συναρτήσεις.
}

Ο χαρακτήρας του συστήματος που αναπτύχθηκε είναι αυστηρά περιορισμένος από τους πόρους του μικροελεγκτή. Ο μικροελεγκτής που χρησιμοποιήθηκε έχει μόλις 384KB από στατική \ac{RAM} διαθέσιμη για τις λειτουργίες του υποσυστήματος. Περαιτέρω, για να επιτευχθούν οι στόχοι αξιοπιστίας η ομάδα αποφάσισε να απαγορεύσει την δυναμική εκχώρηση μνήμης στο λογισμικό του δορυφόρου. Οι δύο αυτοί περιορισμοί συνδράμουν στην δυσκολία της υλοποίησης, καθώς η ανάπτυξη γίνεται με την χρήση της γλώσσας C++, η οποία δεν παρέχει εύκολη υποστήριξη για την διαχείριση της μνήμης. Από την αρχή της ανάπτυξης του λογισμικού, η ομάδα επέλεξε να χρησιμοποιήσει την βιβλιοθήκη \ac{ETL}, \marginnote{
	\href{https://etlcpp.com}{Σύνδεσμος για την αρχική σελίδα της Embedded Template Library}
} η οποία προσφέρει συναρτήσεις ανάλογες της C++ Standard Library (STL). Η σημαντική διαφοροποίηση στις δύο βιβλιοθήκες είναι ότι η \ac{ETL} δίνει τη δυνατότητα χρήσης αποκλειστικά \textbf{στατικά εκχωρημένης μνήμης}. Για να το επιτύχει αυτό, ο προγραμματιστής πρέπει να ορίσει το μέγιστο μέγεθος για όλους τους τύπους κοντέινερ. Για παράδειγμα, ένα μήνυμα πρέπει να έχει αυστηρά ορισμένο μέγεθος στον πίνακα των δεδομένων του, και μία ουρά πρέπει να έχει ορισμένο το μέγιστο μέγεθός της. Αυτός ο περιορισμός επιβάλλει την χρήση της μνήμης με πολύ προσεκτικό τρόπο, καθώς η χρήση μνήμης που δεν έχει αναλογιστεί μπορεί να οδηγήσει σε απρόβλεπτες συμπεριφορές του προγράμματος. Παρόλα αυτά, η ομάδα κατάφερε να υλοποιήσει ένα σύστημα που ικανοποιεί τις απαιτήσεις του δορυφόρου, χωρίς να θυσιάσει την αξιοπιστία του.

Με βάση τη λειτουργικότητα του FreeRTOS, μπορούμε να εξετάσουμε το μέγεθος της στατικά εκχωρημένης μνήμης μίας διεργασίας, για να εκτιμήσουμε τη χωρική πολυπλοκότητα του σχετικού κώδικα. Το σύστημα επικοινωνίας μέσω \ac{CAN} περιέχεται εξ'ολοκλήρου στις δύο διεργασίες του FreeRTOS, \texttt{CANGatekeeperTask} και \texttt{CANTestTask}. Η εκτίμηση αυτή έγινε σε χρόνο εκτέλεσης, όπου το λογισμικό του δορυφόρου έτρεχε σε μία πλακέτα ανάπτυξης SAMV71 Xplained Ultra Board. Για την διαδικασία εκτέλεσης και αποσφαλμάτωσης χρησιμοποιήθηκαν τα λογισμικά \href{https://openocd.org/}{OpenOCD} και \href{https://www.gnu.org/savannah-checkouts/gnu/gdb/index.html}{GDB}. Η χρήση του λογισμικού GDB προσφέρει δύο εξαιρετικά χρήσιμες ιδιότητες για αυτή την ανάλυση. Αρχικά, το GDB λειτουργεί χωρίς γραφικό περιβάλλον, όπου ο χρήστης αλληλεπιδρά με το σύστημα αποσφαλμάτωσης με εντολές κειμένου στο τερματικό. Η λειτουργία αυτή είναι ιδιαίτερα χρήσιμη για την καταγραφή των συνεδριών αποσφαλμάτωσης. Με αντίστοιχο τρόπο εξάχθηκαν τα δεδομένα που εμφανίζονται στον παρακάτω πίνακα. Επιπλέον, το λογισμικό είναι εύκολα επεκτάσιμο και υπάρχει πληθώρα πακέτων που βελτιώνουν την εμπειρία αποσφαλμάτωσης συστημάτων που χρησιμοποιούν το FreeRTOS. Χρησιμοποιώντας το εξαιρετικό εργαλείο \href{https://github.com/espressif/freertos-gdb}{FreeRTOS-gdb} από την Espressif, είναι πολύ εύκολο να εξάγουμε δεδομένα σχετικά με τις δομές του FreeRTOS με τις εντολές:

\marginnote{
	\href{https://github.com/espressif/freertos-gdb}{Το αποθετήριο του εργαλείου FreeRTOS-gdb από την Espressif στο GitHub.}
}

\begin{itemize}
	\item \mintinline{bash}|freertos task| για την εμφάνιση πληροφοριών σχετικά με τα ενεργά \texttt{FreeRTOS Tasks}.
	\item \mintinline{bash}|freertos queue| για την εμφάνιση πληροφοριών σχετικά με τα \texttt{FreeRTOS Queues} τα οποία είναι εγγεγραμμένα στο Queue Registry (το οποίο παρουσιάστηκε στην \Cref{sec:queue-registry}).
	\item \mintinline{bash}|freertos semaphore| για την εμφάνιση πληροφοριών σχετικά με τα ενεργά \texttt{FreeRTOS Semaphores}.
	\item \mintinline{bash}|freertos timer| για την εμφάνιση πληροφοριών σχετικά με τα \texttt{FreeRTOS Timers}.
\end{itemize}

Για την παρούσα ανάλυση χρησιμοποιήθηκε η εντολή \mintinline{bash}{freertos task}. Όπως φαίνεται στον πίνακα, η χρήση μνήμης από τις διεργασίες σχετικές με το \ac{CAN} Bus στο λογισμικό του νανοδορυφόρου χρησιμοποιούν 228 και 1308 λέξεις αντίστοιχα. Αυτό φαίνεται στη στήλη SS του παρακάτω πίνακα, το οποίο συμβολίζει το Stack Size. Με βάση τη ρύθμιση του λογισμικού του νανοδορυφόρου, μία λέξη ορίζεται ως ένας μη-προσημασμένος ακέραιος αριθμός με μέγεθος 32-bit. Στην προκειμένη περίπτωση η αναπαράσταση των δεδομένων δεν έχει καμία επίδραση στη λειτουργικότητα του κώδικα, όμως μπορούμε να συμπεράνουμε ότι για την εύρεση του μεγέθους στοίβας που χρησιμοποιείται σε byte αρκεί να πολλαπλασιάσουμε τον αριθμό λέξεων επί 4. Το γεγονός αυτό ισχύει διότι μία λέξη των 32-bit ισούται με 4-byte.
\begin{figure*}
	\inputminted[breaklines=false,linenos=false]{c++}{code/examples/can-memory-usage.cpp}
	\label{tab:can-memory-usage}
	\caption[Πίνακας με την χρήση μνήμης από τις διεργασίες του \ac{CAN} Bus]{Πίνακας με την χρήση μνήμης από τις διεργασίες του \ac{CAN} Bus}
\end{figure*}

Στην προκειμένη περίπτωση το \texttt{CANGatekeeperTask} χρησιμοποιεί $ 228 \times 4 = 912 $ bytes χώρου στη μνήμη και το \texttt{CANTestTask} χρησιμοποιεί $ 1308 \times 4 = 5232 $ bytes. Ο μικροελεγκτής SAMV71 που χρησιμοποιείται στα 3 από τα 4 υποσυστήματα της ομάδας, παρέχει 384kB από \ac{SRAM} για τις ανάγκες προσωρινής μνήμης της εφαρμογής. Όπως μπορούμε να συμπεράνουμε, το σύστημα του \ac{CAN} χρησιμοποιεί μόλις $ 6144 / 384000 = 0.16\% $ της συνολικής μνήμης του μικροελεγκτή. Αυτό σημαίνει ότι η χρήση της μνήμης από το σύστημα του \ac{CAN} είναι αμελητέας σημασίας και δεν αποτελεί πρόβλημα για την υλοποίηση του λογισμικού του δορυφόρου.

\clearpage
\section{Επίπεδα λογισμικού}
Όπως όλα τα έργα λογισμικού μεγάλης κλίμακας, το κομμάτι λογισμικού της υλοποίησης του \ac{CAN} Bus για τον δορυφόρο χρησιμοποιεί επίπεδα αφαίρεσης. Τα επίπεδα αφαίρεσης χωρίζουν τον κώδικα σε διαφορετικές ενότητες που εκτελούν συγκεκριμένες λειτουργίες. Η πρακτική αυτή έχει πολλά πλεονεκτήματα, καθώς προσφέρει ευκολία στην ανάγνωση, επέκταση, και συντήρηση του λογισμικού. Ο τρόπος με τον οποίο επιτυγχάνεται αυτό είναι η ενθυλάκωση περίπλοκων λειτουργιών και επεξεργασιών δεδομένων γύρω από απλές μεθόδους. Όπως αναφέρεται παρακάτω, στον κώδικα έχουν δημιουργηθεί συναρτήσεις που προσφέρουν αυτά τα επίπεδα αφαίρεσης, καθώς δέχονται δεδομένα υψηλού επιπέδου, και εκτελούν τις διαδικασίες πακετοποίησης, χρήσης ουρών με thread-safe τρόπο και αποστολής μηνυμάτων με αδιαφανή τρόπο για το χρήστη.

Η αφαίρεση αυτή διευκολύνει τη χρήση του λογισμικού από νέους χρήστες, καθώς δεν απαιτούνται εξειδικευμένες γνώσεις επάνω στο αντικείμενο, όπως συνήθως απαιτείται σε λειτουργία περιφερειακών γύρω από ενσωματωμένα συστήματα. Ας δούμε, λοιπόν, τα επίπεδα λογισμικού που υλοποιήθηκαν για το λογισμικό του \ac{CAN} Bus.

\begin{itemize}
	\item \textbf{Application Layer}: Το υψηλότερο επίπεδο κώδικα που θα χρησιμοποιηθεί στην αποστολή. Η χρήση των συναρτήσεων που έχουν υλοποιηθεί στο επίπεδο του Application Layer δεν απαιτεί καμία γνώση από τις λεπτομέρειες του περιβάλλοντος υλοποίησης. Για παράδειγμα, η συνάρτηση \mintinline{c++}|createRequestParametersMessage()| απαιτεί μόνο τον ορισμό του παραλήπτη, και του πίνακα με τα αναγνωριστικά παραμέτρων που ζητούνται. Η διαδικασία μετατροπής του μηνύματος στο πρωτόκολλο \ac{CAN-TP}, η αποστολή και η λήψη από τον παραλήπτη γίνονται αυτόματα. Επίσης αυτόματη είναι η απάντηση από τη πλευρά του παραλήπτη με τη συνάρτηση \mintinline{c++}|createSendParametersMessage()|, όπου αποστέλλονται οι παράμετροι που ζητήθηκαν στη μορφή που ορίστηκε από την ομάδα στο AcubeSAT specific πρωτόκολλο. Τέλος, το σύστημα διαβάζει το μήνυμα, ή τη σειρά μηνυμάτων, με τις παραμέτρους και ανανεώνει τις τιμές τους. Το επίπεδο αυτό είναι διαμορφωμένο με τρόπο ώστε να καλύπτει τις ανάγκες της αποστολής, όμως η υλοποίηση γενικεύεται αρκετά ώστε να μπορεί να αναπτυχθεί σε οποιαδήποτε αρχιτεκτονική χρειαστεί στο μέλλον.
	\item \textbf{TP Protocol}: Το επίπεδο του TP Protocol αφορά το πακετάρισμα και την αποστολή μηνυμάτων μέσω του \ac{CAN}. Είναι βασισμένο στο πρωτόκολλο ISO 15765\dualcite{iso157652016}, παραλείποντας τα μηνύματα που αφορούν τον έλεγχο ροής δεδομένων (Flow Control). Η χρήση του πρωτοκόλλου επιτρέπει την αποστολή μηνυμάτων με μέγεθος μεγαλύτερο από 64-byte, το μέγιστο επιτρεπτό μέγεθος στην επέκταση \ac{CAN-FD}. Όταν είναι απαραίτητο, τα μηνύματα χωρίζονται και αναδιαμορφώνονται σε πακέτα των 64-byte, χωρίς να απαιτείται προεργασία στο μήνυμα από ανώτερα επίπεδα. Αυτή τη στιγμή το πρωτόκολλο \ac{CAN-TP} υλοποιήθηκε με βασικό \textbf{Error Detection \& Handling}, λόγω του σταδίου ανάπτυξης του συστήματος. Η ομάδα έχει σκοπό να αναπτύξει την υλοποίηση ώστε να καλύπτει συγκρούσεις και απώλεια δεδομένων με ευλάβεια, όταν έρθει η ώρα ανάπτυξης του συστήματος \ac{FDIR} του δορυφόρου.
	\item \textbf{FreeRTOS}: Το επίπεδο του FreeRTOS αναφέρεται αποκλειστικά στη διεργασία CANGatekeeperTask, η οποία εκτελείται περιοδικά ως FreeRTOS Task. Η διεργασία αυτή υλοποιεί ουρές για εισερχόμενα και εξερχόμενα μηνύματα και εκτελεί διαδικασίες ανίχνευσης και αναφοράς σφαλμάτων. Τέλος, η διεργασία προστατεύει το περιφερειακό από ταυτόχρονη πρόσβαση δύο ή παραπάνω διεργασιών, αφού το σύστημα χρησιμοποιεί pre-emptive multitasking, γεγονός που μπορεί να διακόψει μία διεργασία για την εκτέλεση άλλης με μεγαλύτερη σημαντικότητα προτού αυτή ολοκληρώσει την εργασία της. Οι αρμοδιότητες του CANGatekeeperTask κρίνονται εξαιρετικά σημαντικές για τη λειτουργία του διαύλου και θα αναλυθούν με περισσότερη λεπτομέρεια στο \Cref{sec:gatekeeper}.
	\item \textbf{Driver}: Το χαμηλότερο επίπεδο κώδικα που σχετίζεται με τις ανάγκες της αποστολής. Το επίπεδο Driver περιέχεται στα αρχεία Driver.cpp και Driver.hpp, και οδηγεί το ενσωματωμένο περιφερειακό του μικροελεγκτή κατά τη διάρκεια της αρχικοποίησης αλλά και της αποστολής και λήψης δεδομένων. Στο επίπεδο αυτό ορίζονται συναρτήσεις που διαφέρουν ανά μικροελεγκτή, χάρη στη σύνδεση και το \ac{API}, που έχει οριστεί από τον κατασκευαστή. Οι συναρτήσεις αυτές περιλαμβάνουν την εξαγωγή δεδομένων από το περιφερειακό κατά τη διάρκεια ενός \ac{ISR}, τη μετατροπή των δεδομένων του μηνύματος στην μορφή που χρησιμοποιεί ο κατασκευαστής, κ.α.
\end{itemize}

Είναι άξιο να σημειωθεί ότι το επίπεδο Driver είναι το μόνο επίπεδο που χρήζει τροποποίησης, όταν ο κώδικας μεταφέρεται σε διαφορετικό μοντέλο μικροελεγκτή. Για παράδειγμα, η ομάδα που συνδράμει στο project \textit{PeakSat} χρησιμοποιεί την υλοποίηση σε μικροελεγκτή της \textbf{STMicroelectronics}. Για την χρήση αυτή αντιγράφθηκαν οι επιλογές του περιφερειακού στο αντίστοιχο πρόγραμμα διαμόρφωσης, και τροποποιήθηκαν οι συναρτήσεις του Driver. Η επικοινωνία μεταξύ μικροελεγκτή STM και Atmel SAMV71 ήταν επιτυχής χωρίς καμία περαιτέρω αλλαγή. Χάρη στο υψηλό επίπεδο αφαίρεσης του Application Layer είναι εύκολη και γρήγορη η ενσωμάτωση του κώδικα σε νέο περιβάλλον.

\clearpage
\section{Διεπαφή με τον κώδικα του περιφερειακού}
Το χαμηλότερο επίπεδο κώδικα στην υλοποίηση της εργασίας ήταν και το πολυπλοκότερο. Σε αυτό, συμμετέχουν πολλές παράμετροι οι οποίες δεν είναι δυνατό να απομονωθούν προτού έχουμε ολοκληρωμένη εικόνα του συστήματος. Με σκοπό την επιτάχυνση της ανάπτυξης του συστήματος, αναζητήθηκαν πρότζεκτ ανοιχτού κώδικα που χρησιμοποιούν το \ac{CAN} Bus σε αντίστοιχο μικροελεγκτή της κατασκευαστικής εταιρείας Microchip, χωρίς επιτυχία. Για τον παραπάνω σκοπό, η Microchip διαθέτει ένα αποθετήριο ανοιχτού κώδικα στο GitHub, \marginnote{\href{https://github.com/Microchip-MPLAB-Harmony/csp_apps_sam_e70_s70_v70_v71/tree/master/apps/mcan/mcan_fd_operation_interrupt_timestamp}{Σύνδεσμος για το αποθετήριο στο GitHub}} στο οποίο προσφέρει παραδείγματα χρήσης για τα περιφερειακά της. Σε αυτά αναδεικνύει την απαραίτητη συνδεσμολογία και τη σωστή χρήση των συναρτήσεων που παρέχει. Το παράδειγμα του κατασκευαστή \textit{τρέχει} στη πλακέτα και προσφέρει μία διεπαφή στο χρήστη μέσω της σειριακής σύνδεσης \ac{UART}, η οποία μεταφέρεται μέσω της σύνδεσης USB ανάμεσα στη πλακέτα και τον υπολογιστή. Η διεπαφή δείχνει τις παρακάτω επιλογές που απαρτίζουν διαφορετικά μηνύματα με προκαθορισμένα πεδία αναγνωριστικού και δεδομένων. Η συγκεκριμένη εφαρμογή, παρά την χαμηλή της πολυπλοκότητα, βοήθησε στην κατανοήση της ρύθμισης και χρήσης των περιφερειακών αλλά και στην ανάπτυξη εφαρμογής λήψης, εφ'όσον υπήρχε κόμβος στο δίκτυο τον οποίο μπορούσαμε να θεωρήσουμε λειτουργικό με σιγουριά.

\begin{figure*}[ht]
	\includegraphics[width=0.8\linewidth]{media/images/microchip-example-menu.png}
	\label{fig:microchip-example-menu}
	\caption[Το μενού αποστολής μηνυμάτων στο παράδειγμα της Microchip]{Το μενού αποστολής μηνυμάτων στο παράδειγμα της Microchip}
\end{figure*}

\par Στο παράδειγμα του \href{https://github.com/Microchip-MPLAB-Harmony/csp_apps_sam_e70_s70_v70_v71/tree/master/apps/mcan/mcan_fd_operation_interrupt_timestamp}{συνδέσμου} ο δημιουργός του αποθετηρίου περιγράφει το απλούστερο λειτουργικό παράδειγμα συνδεσμολογίας ανάμεσα σε δύο πλακέτες SAMV71 Xplained Ultra, το ίδιο μοντέλο που χρησιμοποιεί και η ομάδα. Όπως περιγράφεται από τον οδηγό, οι δύο πλακέτες συνδέονται με χρήση τριών καλωδίων jumper στις ακόλουθες θύρες:

\par Αρχικά, συνδέουμε τις θύρες CANH και CANL των πλακετών στο δίαυλο. Οι δύο πλακέτες προσφέρουν ενσωματωμένο \ac{CAN} transceiver, ο οποίος είναι τοποθετημένος στην νότια άκρη της πλακέτας, όταν αυτή είναι τοποθετημένη με τις θύρες USB στην βόρεια άκρη. Δίπλα στον \ac{CAN} transceiver είναι τοποθετημένα δύο male headers τα οποία δίνουν πρόσβαση στις εξόδους του transceiver, CANH και CANL. Στα αρχικά στάδια της εργασίας, η σύνδεση αυτή έγινε χρησιμοποιώντας ένα breadboard ως διαμεσολαβητή. Στην παρακάτω εικόνα φαίνεται η σύνδεση των δύο πλακετών μέσω του breadboard.

\begin{figure}[ht]
	\centering
	\includegraphics[angle=270,origin=c]{media/images/lab-wiring-scope.jpg}
	\label{fig:lab-wiring-scope}
	\caption[Συνδεσμολογία δυό πλακέτων μέσω του breadboard]{Συνδεσμολογία δυό πλακέτων μέσω του breadboard. Επίσης συνδεδεμένα φαίνονται και τα δύο κανάλια του παλμογράφου στις γραμμές CANH και CANL.}
\end{figure}

Η χρήση breadboard μας δίνει τη δυνατότητα να χρησιμοποιήσουμε ένα παλμογράφο ώστε να διαγνώσουμε προβλήματα στη διαμόρφωση του καναλιού. Οι ιδιαιτερότητες του κώδικα διεπαφής από το κατασκευαστή, σε συνδυασμό με το σύνολο λογισμικού που επέλεξε η ομάδα να χρησιμοποιήσει, διεσχέρυναν την διαδικασία έως τη πρώτη επιτυχή μετάδοση μηνύματος. Στην εικόνα φαίνεται το αποτέλεσμα στον παλμογράφο ως τετραγωνικός παλμός, όμως το μήνυμα δεν εμφανίζεται στη σειριακή έξοδο από το μικροελεγκτή. Παρακάτω θα περιγραφούν τα προβλήματα που προέκυψαν και οι λύσεις που βρέθηκαν.

Αρχικά, όπως φαίνεται και στο παράδειγμα κώδικα του κατασκευαστή, χρησιμοποιούνται πράξεις bit-shifting για την κωδικοποίηση του αναγνωριστικού αποστολέα στα μηνύματα. Κάθε αναγνωριστικό είναι μετατοπισμένο κατά 18 bit στα αριστερά όσο αυτό βρίσκεται σε επίπεδο περιφερειακού και κάτω. Η παρατήρηση αυτή έγινε παρατηρώντας τον κώδικα του παραδείγματος, όπου ο δημιουργός του χρησιμοποιεί την ίδια κωδικοποίηση. Στη βιβλιογραφία του μικροελεγκτή \dualcite{datasheet} δεν αναφέρεται τίποτα σχετικό, και η ομάδα υποθέτει ότι παρά τη χρήση standard \ac{ID} (11-bit) έναντι extended \ac{ID} (29-bit), διαβάζονται μόνο τα 11 Most-Significant Bits (MSB) του αριθμού.

\marginnote{
	Τα Most-Significant-Bits ενός δυαδικού αριθμού είναι αυτά που βρίσκονται στην αριστερή πλευρά του αριθμού, και έχουν τη μεγαλύτερη σημασία. Αντίθετα, τα Least-Significant-Bits είναι αυτά που βρίσκονται στη δεξιά πλευρά του αριθμού, και έχουν τη μικρότερη σημασία.
}

Η δεύτερη ιδιαιτερότητα του διαύλου ήταν η επιλογή της συχνότητας εισόδου στο \ac{CAN} transceiver. Στη βιβλιογραφία \cite{datasheet}, ο κατασκευαστής προτείνει μία από τις επιλογές των 20MHz, 40MHz ή 80MHz. Όπως αναφέρθηκε παραπάνω, το παράδειγμα του κατασκευαστή χρησιμοποιήθηκε για την ανάπτυξη και την επαλήθευση της υλοποίησης. Το παράδειγμα του κατασκευαστή χρησιμοποιεί συχνότητα εισόδου για το \ac{CAN} ίση με 50MHz. Η επιλογή αυτή δεν δικαιολογείται από τον κατασκευαστή με κάποιο τρόπο, όμως είναι λειτουργική. Η ομάδα υποθέτει ότι η επιλογή διευκολύνει την παραμετροποίηση των ρολογιών του συστήματος καθώς μπορεί πολύ εύκολα να χρησιμοποιηθεί το Master Clock (MCK) ως αρχικό σήμα για το ρολόι του \ac{CAN}. Το Master Clock χρησιμοποιείται ως βάση για τη ρύθμιση των υπόλοιπων ρολογιών που αφορούν τα περιφερειακά του συστήματος. Το Master Clock στην προκειμένη περίπτωση, έχει συχνότητα ίση με το μισό του ρολογιού του επεξεργαστή και εφόσον ο επεξεργαστής είναι χρονισμένος στα 300MHz, ο ρυθμός του MCK είναι τα 150MHz. Χρησιμοποιώντας έναν διαιρέτη, όπως διαμορφώνεται εύκολα από το MPLAB Configurator, μπορούμε να διαιρέσουμε τη συχνότητα του MCK δια τρία, ώστε να καταλήξουμε με ρολόι εισόδου στα 50MHz. Η συχνότητα αυτή είναι μέσα στο εύρος των επιλογών του κατασκευαστή και η επιλογή της δεν έχει καμία επίπτωση στην επικοινωνία μεταξύ των δύο πλακετών.

\begin{figure*}
	\includegraphics[width=0.8\linewidth]{media/images/mplab-clock-diagram.png}
	\label{fig:mplab-clock}
	\caption{Διάγραμμα ρύθμισης ρολογιών από το MPLAB X \acs{IDE}}
\end{figure*}

Η τρίτη και πολυπλοκότερη ιδιαιτερότητα του συστήματος είναι η διαχείριση της κοινής μνήμης ανάμεσα στο περιφερειακό και τον επεξεργαστή. Η κοινή μνήμη χρησιμοποιείται για την αποθήκευση των μηνυμάτων που πρόκειται να αποσταλούν ή να ληφθούν από το περιφερειακό και στην περίπτωση του μικροελεγκτή SAMV71Q21B ονομάζεται \textbf{Message \ac{RAM}} \dualcite{datasheet} από τον κατασκευαστή. Όπως είναι κατανοητό, η αλληλεπίδραση των δύο διαφορετικών συστημάτων στο ίδιο πεδίο μνήμης υπόκειται σε ορισμένους περιορισμούς. Οι περιορισμοί αυτοί προέρχονται από την αρχιτεκτονική του περιφερειακού, την ανάγκη για ταχεία επεξεργασία δεδομένων σε αυτό και την ανάγκη για την έγκυρη μετάδοση δεδομένων μεταξύ των δύο συσκευών.

\begin{marginfigure}
	\centering
	\includegraphics[width=0.9\linewidth]{images/message-ram.png}
	\caption[Διάγραμμα της Message \ac{RAM}]{Διάγραμμα της Message \ac{RAM}. Η εικόνα προέρχεται από τη βιβλιογραφία του μικροελεγκτή}
	\label{fig:message-ram}
\end{marginfigure}

Η περιοχή της Message \ac{RAM} προσφέρει μόνο αποθηκευτικό χώρο για τα φίλτρα εισερχομένων μηνυμάτων και για τα μηνύματα προς ανταλλαγή με το δίαυλο. Σε ενσωματωμένα συστήματα στα οποία ενδιαφερόμαστε μονάχα για την αποθήκευση δεδομένων και όχι για την αναπαράσταση, η μνήμη αποθήκευσης είναι συνήθως οργανωμένη σε ένα πίνακα με τύπο \mintinline{c++}|uint8_t mcan0MessageRAM[MCAN0_MESSAGE_RAM_CONFIG_SIZE];|. Η έκφραση \texttt{MCAN0\_MESSAGE\_RAM\_CONFIG\_SIZE} παράγεται από τον κατασκευαστή κατά τη διάρκεια παραγωγής κώδικα για το σύστημα και εξασφαλίζει τον απαιτούμενο αποθηκευτικό χώρο με βάση τις ρυθμίσεις του περιφερειακού.

\marginnote{
	Το \href{https://gcc.gnu.org/}{\ac{GCC}} έχει επιλαγεί από την ομάδα ως compiler για τη χρήση του σε όλο το λογισμικό του δορυφόρου
}
Το χαμηλού επιπέδου λογικής περιφερειακό \textbf{MCAN} απαιτεί πρόσβαση σε λέξεις των 32-bit. Για αυτό το σκοπό είναι απαραίτητο ο πίνακας που έχει οριστεί να βρίσκεται τοποθετημένος κατάλληλα στη μνήμη ώστε να εξασφαλιστεί η πρόσβαση του περιφερειακού σε αυτή. Η έννοια αυτή λέγεται ευθυγράμμιση μνήμης και εξηγείται με λεπτομέρεια στο \dualcite{sehr2018cpp}. Όπως εξηγείται στο κεφάλαιο 6.34.1 του \dualcite{GCCManual}, μπορούμε να ορίσουμε \emph{χαρακτηριστικά} στις μεταβλητές, συμπεριλαμβανομένης και της ευθυγράμμισης τους. Ως αποτέλεσμα, ο παραπάνω πίνακας πλέον ορίζεται ως \inputminted{c++}{code/examples/message-ram/alignment.cpp} Πλέον, η διεύθυνση μνήμης στην οποία θα αποθηκευτεί ο πίνακας είναι πολλαπλάσια του 4 και καλύπτει την απαίτηση του περιφερειακού.

\marginnote{
	Η κρυφή μνήμη του επεξεργαστή αποθηκεύει πρόσφατα χρησιμοποιούμενα δεδομένα, για να μεγιστοποιήσει την απόδοση της εφαρμογής. Τα δεδομένα αυτά απολύονται από την κρυφή μνήμη με μία πολιτική Least Recently Used (LRU).
}

\marginnote{
	Η αποδοτική χρήση της κρυφής μνήμης είναι ύψιστης σημασίας για την απόδοση των επεξεργαστών.
}

Το δεύτερο πρόβλημα που πρέπει να αντιμετωπιστεί για την ορθή λειτουργία της κοινής μνήμης είναι η αλληλεπίδραση του επεξεργαστή με την περιοχή αυτή. Όπως αναφέρθηκε, στη κοινή μνήμη αποθηκεύονται δεδομένα από το περιφερειακό χωρίς όμως την ειδοποίηση του επεξεργαστή για αυτό. Με αυτή τη συμπεριφορά γεννούνται προβλήματα διότι ο επεξεργαστής χρησιμοποιεί μηχανισμούς κρυφής μνήμης. Σε περίπτωση που ο επεξεργαστής δράσει στη κοινή μνήμη, τα περιεχόμενά της θα διατηρηθούν στη κρυφή μνήμη \dualcite{williams2012c++}. Εάν το περιφερειακό ενημερώσει αυτά τα δεδομένα και καλέσει το αντίστοιχο interrupt του επεξεργαστή έγκαιρα, αυτός θα πράξει πάνω στα δεδομένα της κρυφής μνήμης, σε αντίθεση με τα δεδομένα της κοινής μνήμης Message \ac{RAM}. Αυτό θα οδηγήσει σε λανθασμένη λειτουργία του περιφερειακού καθώς θα επιχειρεί να διαβάσει δεδομένα που δεν είναι πλέον έγκυρα. Μία λύση σε αυτό το πρόβλημα είναι η χρήση της συνάρτησης στο \Cref{algorithm:cache-clean-routine}, η οποία εξασφαλίζει την εκκαθάριση της κοινής μνήμης. Η χρήση της συνάρτησης αυτής είναι απαραίτητη σε όλες τις περιπτώσεις που ο επεξεργαστής δρα στην κοινή μνήμη, όμως η χρήση αυτής μειώνει την απόδοση του συστήματος όταν αυτό εκτελεί οποιαδήποτε διαδικασία για το \ac{CAN} Bus. Ως αποτέλεσμα το τελικό σύστημα υλοποιεί μία πιο κομψή μέθοδο.

\begin{figure*}
	\inputminted{asm}{code/examples/cache-clean-routine.asm}
	\label{algorithm:cache-clean-routine}
	\caption[Συνάρτηση εκκαθάρισης Data Cache]{Συνάρτηση εκκαθάρισης Data Cache σε ARMv7 Assembly}
\end{figure*}

Κατά τη διάρκεια της ανάπτυξης του λογισμικού, βρέθηκε ορθότερη μέθοδος για την διαχείριση της κρυφής μνήμης όσον αφορά τις διαδικασίες του διαύλου. Η μέθοδος περιλαμβάνει τον ορισμό μίας περιοχής μνήμης η οποία δεν υπάγεται στην πολιτική της κρυφής μνήμης. Για την υλοποίηση του μηχανισμού αυτού απαιτούνται τρείς ενέργειες. Αρχικά, πρέπει να δημιουργήσουμε μία νέα περιοχή μνήμης στο linker script. Η δημιουργία της περιοχής περιλαμβάνεται στο \Cref{code:linker-diff}. Ο ορισμός απαιτεί δύο πεδία, την θέση της περιοχής στη μνήμη και το μέγεθός της. Καθώς το λογισμικό του μικροελεγκτή πριν την αλλαγή τοποθετούσε τη μνήμη \ac{RAM} στη θέση \texttt{0x20400000} με μέγεθος \texttt{0x00060000} bytes, αποφασίστηκε η νέα περιοχή μνήμης να τοποθετηθεί στο τέλος της \ac{RAM}. Για αυτό το σκοπό πρώτα υπολογίστηκε το μέγεθος που απαιτεί η \texttt{Message \ac{RAM}} για τα περιφερειακά MCAN0 και MCAN1. Αυτό έγινε ελέγχοντας τις μεταβλητές \mintinline{c++}|#define MCAN0_MESSAGE_RAM_CONFIG_SIZE     2964U| και \mintinline{c++}|#define MCAN1_MESSAGE_RAM_CONFIG_SIZE     2964U| στο αρχείο \texttt{plib\_mcan\_common.h} του λογισμικού του μικροελεγκτή. Καθώς χρειάζεται να οριστεί ένας πίνακας Message \ac{RAM} για κάθε περιφερειακό από τα MCAN0 και MCAN1, συνολικά απαιτούνται 5928 bytes. Στη διαμόρφωση της περιοχής μνήμης στο MPLAB δίνονται επιλογές για μεγέθη που είναι πολλαπλάσια του 2, οπότε η μικρότερη επιλογή που αρκεί είναι τα 8KB. Στη συνέχεια, υπολογίστηκε η θέση της περιοχής μνήμης η οποία είναι ίση με την θέση της \ac{RAM} συν το μέγεθός της μείον το μέγεθος των \texttt{Message \ac{RAM}}. Το αποτέλεσμα είναι ίσο με \texttt{0x20400000 + 0x0060000 - 0x00002000 = 0x2045E000}. Τέλος, ορίστηκε το μέγεθος της περιοχής μνήμης ως \texttt{0x00002000} bytes. Η περιοχή μνήμης αυτή ονομάστηκε \texttt{SRAM\_NOCACHE} και ο ορισμός της περιλαμβάνεται στο \Cref{code:linker-diff}.

\marginnote{
	Το linker script είναι ένα αρχείο κειμένου το οποίο περιέχει οδηγίες για τον linker του \ac{GCC}. Ο linker είναι το τελευταίο πρόγραμμα που εκτελείται κατά τη διάρκεια της διαδικασίας μεταγλωττισμού. Ο linker συνδέει τα αρχεία αντικειμένου που παράγονται από τον compiler, και δημιουργεί το τελικό εκτελέσιμο αρχείο.
}

\begin{figure*}
	\inputminted{c++}{code/examples/diff-linker.ld}
	\label{code:linker-diff}
	\caption[Ορισμός περιοχής στο linker script]{Ορισμός περιοχής στο linker script. Οι γραμμές που περιέχουν τελείες στην αρχή είναι αυτές που είναι απαραίτητες για τη δημιουργία μίας νέας περιοχής μνήμης}
\end{figure*}

Στη συνέχεια, πρέπει να ορίσουμε την περιοχή αυτή ως \mintinline{c++}|non-cacheable|, ώστε να μην υπάγεται στην πολιτική της κρυφής μνήμης. Η διαδικασία αυτή γίνεται χρησιμοποιώντας το MPLAB X \ac{IDE}, όπως γίνεται και η πλειοψηφία ενεργειών διαμόρφωσης του μικροελεγκτή. Η διαδικασία αυτή περιλαμβάνει την ενεργοποίηση της \ac{MPU} του μικροελεγκτή, η οποία είναι υπεύθυνη για την επιβολή των περιορισμών πρόσβασης στη μνήμη. Η ενεργοποίηση της \ac{MPU} γίνεται μέσω γραφικού περιβάλλοντος και η ρύθμιση φαίνεται στο \Cref{fig:mpu-settings}. Από το γραφικό περιβάλλον ρυθμίζουμε τον τύπο της μνήμης σε αυτή την περιοχή ως \mintinline{c++}|non-cacheable| και έπειτα ορίζουμε την διεύθυνση της περιοχής μνήμης αλλά και το μέγεθός της. Οι επιλογές περιγράφηκαν στην παραπάνω παράγραφο και οι αντίστοιχες ρυθμίσεις έγιναν στο γραφικό περιβάλλον.

\begin{figure*}
	\includegraphics[width=0.9\linewidth]{images/mplab-mpu-settings.png}
	\label{fig:mpu-settings}
	\caption[Ορισμός ρυθμίσεων της \ac{MPU}]{Ορισμός ρυθμίσεων του Memory Protection Unit. Η περιοχή που ορίζεται ως non-cacheable για την λειτουργία του \ac{CAN} είναι η \texttt{SRAM\_NOCACHE}}
\end{figure*}

Η τελική ενέργεια που απαιτείται για τη χρήση του μηχανισμού είναι η αποθήκευση των πινάκων Message \ac{RAM} στην ξεχωριστή περιοχή μνήμης. Για το σκοπό αυτό χρησιμοποιείται πάλι η επιλογή \texttt{attributes} του \ac{GCC} με τον ακόλουθο τρόπο \inputminted{c++}{code/examples/message-ram/full.cpp}

Πλέον έχουμε μία αποδοτική και ασφαλή μεταφορά δεδομένων μεταξύ του επεξεργαστή και του περιφερειακού για το \ac{CAN} χωρίς το ενδεχόμενο να παράγονται σφάλματα λόγω της κρυφής μνήμης.

% \clearpage
\section{Η διαδρομή ενός μηνύματος}

Τα περισσότερα μηνύματα που μεταφέρονται μέσω \ac{CAN} είναι αυτοματοποιημένα και περιοδικά. Αφορούν κυρίως την μεταφορά παραμέτρων και τον έλεγχο της εύρυθμης λειτουργίας του συστήματος. Για την περιοδική αποστολή των μηνυμάτων μπορούμε να βασιστούμε στο λειτουργικό σύστημα που χρησιμοποιείται στον μικροελεγκτή, το FreeRTOS. Η υλοποίηση της λειτουργικότητας του \ac{CAN} είναι στενά συνδεδεμένη με το λειτουργικό σύστημα καθώς χρησιμοποιούνται συναρτήσεις αναμονής, ουρές και σημαιοφόροι που παρέχονται από αυτό. Με βάση τα παραπάνω έχουν υλοποιηθεί οι διεργασίες που φαίνονται στο \Cref{fig:message-send-fsm}.

\begin{figure*}
	\centering
	% TODO: Replace this graphic with a properly rendered one
	\tikzset{every picture/.style={line width=0.75pt}} %set default line width to 0.75pt        

	\begin{tikzpicture}[x=0.75pt,y=0.75pt,yscale=-1,xscale=1]
	%uncomment if require: \path (0,300); %set diagram left start at 0, and has height of 300

	%Rounded Rect [id:dp8283887230862136] 
	\draw   (90,29.13) .. controls (90,26.19) and (92.39,23.8) .. (95.33,23.8) -- (233.86,23.8) .. controls (236.8,23.8) and (239.19,26.19) .. (239.19,29.13) -- (239.19,103.73) .. controls (239.19,106.67) and (236.8,109.05) .. (233.86,109.05) -- (95.33,109.05) .. controls (92.39,109.05) and (90,106.67) .. (90,103.73) -- cycle ;
	%Rounded Rect [id:dp3219665064705105] 
	\draw   (90,159.14) .. controls (90,156.2) and (92.39,153.81) .. (95.33,153.81) -- (233.86,153.81) .. controls (236.8,153.81) and (239.19,156.2) .. (239.19,159.14) -- (239.19,233.73) .. controls (239.19,236.68) and (236.8,239.06) .. (233.86,239.06) -- (95.33,239.06) .. controls (92.39,239.06) and (90,236.68) .. (90,233.73) -- cycle ;
	%Rounded Rect [id:dp9515254816445721] 
	\draw   (283.95,29.13) .. controls (283.95,26.19) and (286.33,23.8) .. (289.28,23.8) -- (427.81,23.8) .. controls (430.75,23.8) and (433.14,26.19) .. (433.14,29.13) -- (433.14,103.73) .. controls (433.14,106.67) and (430.75,109.05) .. (427.81,109.05) -- (289.28,109.05) .. controls (286.33,109.05) and (283.95,106.67) .. (283.95,103.73) -- cycle ;
	%Rounded Rect [id:dp5528663862617004] 
	\draw   (283.95,157.01) .. controls (283.95,154.07) and (286.33,151.68) .. (289.28,151.68) -- (427.81,151.68) .. controls (430.75,151.68) and (433.14,154.07) .. (433.14,157.01) -- (433.14,231.6) .. controls (433.14,234.55) and (430.75,236.93) .. (427.81,236.93) -- (289.28,236.93) .. controls (286.33,236.93) and (283.95,234.55) .. (283.95,231.6) -- cycle ;
	%Rounded Rect [id:dp6557787363812451] 
	\draw   (475.76,93.07) .. controls (475.76,90.13) and (478.15,87.74) .. (481.09,87.74) -- (619.62,87.74) .. controls (622.57,87.74) and (624.95,90.13) .. (624.95,93.07) -- (624.95,167.66) .. controls (624.95,170.61) and (622.57,172.99) .. (619.62,172.99) -- (481.09,172.99) .. controls (478.15,172.99) and (475.76,170.61) .. (475.76,167.66) -- cycle ;
	%Straight Lines [id:da9088633533237458] 
	\draw    (240.03,69.7) -- (282.03,69.7) ;
	\draw [shift={(284.03,69.7)}, rotate = 180] [color={rgb, 255:red, 0; green, 0; blue, 0 }  ][line width=0.75]    (10.93,-3.29) .. controls (6.95,-1.4) and (3.31,-0.3) .. (0,0) .. controls (3.31,0.3) and (6.95,1.4) .. (10.93,3.29)   ;
	%Straight Lines [id:da3379510666494582] 
	\draw    (283.03,199.7) -- (241.03,199.7) ;
	\draw [shift={(239.03,199.7)}, rotate = 360] [color={rgb, 255:red, 0; green, 0; blue, 0 }  ][line width=0.75]    (10.93,-3.29) .. controls (6.95,-1.4) and (3.31,-0.3) .. (0,0) .. controls (3.31,0.3) and (6.95,1.4) .. (10.93,3.29)   ;
	%Straight Lines [id:da038229596084358386] 
	\draw    (433.03,79.7) -- (474.37,107.58) ;
	\draw [shift={(476.03,108.7)}, rotate = 214] [color={rgb, 255:red, 0; green, 0; blue, 0 }  ][line width=0.75]    (10.93,-3.29) .. controls (6.95,-1.4) and (3.31,-0.3) .. (0,0) .. controls (3.31,0.3) and (6.95,1.4) .. (10.93,3.29)   ;
	%Straight Lines [id:da042331571690753966] 
	\draw    (476.03,148.7) -- (434.65,178.53) ;
	\draw [shift={(433.03,179.7)}, rotate = 324.21] [color={rgb, 255:red, 0; green, 0; blue, 0 }  ][line width=0.75]    (10.93,-3.29) .. controls (6.95,-1.4) and (3.31,-0.3) .. (0,0) .. controls (3.31,0.3) and (6.95,1.4) .. (10.93,3.29)   ;
	%Straight Lines [id:da877274474127349] 
	\draw    (160.03,153.7) -- (160.03,110.7) ;
	\draw [shift={(160.03,108.7)}, rotate = 90] [color={rgb, 255:red, 0; green, 0; blue, 0 }  ][line width=0.75]    (10.93,-3.29) .. controls (6.95,-1.4) and (3.31,-0.3) .. (0,0) .. controls (3.31,0.3) and (6.95,1.4) .. (10.93,3.29)   ;

	% Text Node
	\draw (164.59,66.43) node  [font=\footnotesize] [align=left] {FreeRTOS Task\\periodically executes};
	% Text Node
	\draw (358.54,66.43) node  [font=\footnotesize] [align=left] {FreeRTOS Task calls\\Application Layer function};
	% Text Node
	\draw (550.36,130.37) node  [font=\footnotesize] [align=left] {Application Layer function\\creates message object\\and routes it to the\\Gatekeeper's outgoing\\queue};
	% Text Node
	\draw (358.54,194.31) node  [font=\footnotesize] [align=left] {Gatekeeper is notified\\using FreeRTOS task\\notifications and routes\\the message to\\the peripheral};
	% Text Node
	\draw (164.59,196.44) node  [font=\footnotesize] [align=left] {Gatekeeper task goes\\into blocked state};


\end{tikzpicture}
	\label{fig:message-send-fsm}
	\caption[Διάγραμμα καταστάσεων για την αποστολή ενός μηνύματος]{Διάγραμμα μηχανής πεπερασμένων καταστάσεων για την αποστολή ενός μηνύματος}
\end{figure*}

Όπως φαίνεται, βασιζόμαστε στην έννοια των FreeRTOS Task για γεγονότα που επιθυμούμε να εκτελούνται περιοδικά για την εκπλήρωση κάποιων προδιαγραφών, όπως:
\begin{itemize}
	\item Την αποστολή παραμέτρων, για την εκπλήρωση του Data Housekeeping από το \ac{OBC}.
	\item Τον συγχρονισμό του ακριβή χρόνου σε UTC σε όλα τα υποσυστήματα.
	\item Την εκτέλεση διαδικασιών εντοπισμού, απομόνωσης και επιδιόρθωσης σφαλμάτων, μέσω περιοδικών μηνυμάτων \emph{παλμών}. Μέσα από αυτά το \ac{OBC} ανιχνεύει υποσυστήματα τα οποία δεν αποκρίνονται και εκτελεί τις κατάλληλες ενέργειες για την επαναφορά τους. 
\end{itemize}

\section{Η μεταφορά μηνυμάτων ως πακέτα}

Από τον σχεδιασμό του πρωτοκόλλου του \ac{CAN} Bus, ένα μήνυμα αποτελείται κατά μέγιστο από 8-byte στη κλασική έκδοση και 64-byte στην επέκταση \ac{CAN-FD}. Σχεδόν όλοι οι δημιουργοί επεξεργαστών και μικροελεγκτών που αλληλεπιδρούν με το \ac{CAN} χρησιμοποιούν πίνακες ορισμένων μεγεθών από μεταβλητές με τύπο \mintinline{c++}|uint8_t| στις γλώσσες C και C++. Οι μεταβλητές \mintinline{c++}|uint8_t| αναπαριστούν έναν ακέραιο αριθμό, μη-προσημασμένο, με μέγεθος 8-bit. \marginnote{Ο τύπος αυτός χρησιμοποιείται συχνά σε ενσωματωμένα συστήματα όταν η αναπαράσταση των δεδομένων είναι λιγότερο σημαντική από την μεταφορά ή την αποθήκευσή τους.} Η επιλογή αυτή από τους κατασκευαστές οδήγησε σε δύο προβλήματα στην υλοποίηση της διεπαφής του πρωτοκόλλου της ομάδας με το περιφερειακό.

Αρχικά, τα μηνύματα που μεταφέρονται στο πρωτόκολλο \ac{CAN-TP} πολύ συχνά μεταφέρουν μεταβλητές με μέγεθος μεγαλύτερο από αυτό του \mintinline{c++}|uint8_t|. Η αρχική μου ιδέα στο παραπάνω θέμα, ήταν να χρησιμοποιήσω συναρτήσεις που χρησιμοποιούν πρότυπα (templates) και δέχονται μεταβλητές ανεξαρτήτου μεγέθους και τις εισάγουν κατάλληλα σε πίνακα που δέχεται μεταβλητές τύπου \mintinline{c++}|uint8_t|. Ένα παράδειγμα κώδικα σε C++ που υλοποιεί αυτή τη συνάρτηση φαίνεται παρακάτω. 

\begin{figure}
	\inputminted{cpp}{code/examples/stuffInVector.cpp}
	\label{code:stuffInVector}
	\caption[Συνάρτηση για την εισαγωγή μεταβλητών σε πίνακα]{Συνάρτηση για την εισαγωγή μεταβλητών σε πίνακα. Η συνάρτηση αυτή δέχεται μία μεταβλητή οποιουδήποτε μεγέθους και την εισάγει σε έναν πίνακα μεταβλητών τύπου \mintinline{c++}|uint8_t|}
\end{figure}

Η λύση αυτή, παρόλο λειτουργική σε πρώτη ματιά, προσφέρει ελάχιστα από άποψη εργονομίας στον προγραμματιστή και ελέγχου και αναφοράς σφαλμάτων. Η υλοποίηση γεννά πολλούς προβληματισμούς στην ομάδα, όπως για παράδειγμα της συμπεριφοράς σε περίπτωση σφαλμάτων, ή της επιλογής Endianness των δεδομένων (εάν το πιο σημαντικό byte αποθηκεύεται στην προγενέστερη θέση μνήμης, χρησιμοποείται Big-Endian αναπαράσταση). Καθώς η διαδικασία υλοποίησης της εργασίας ήταν ήδη μεγάλη, αποφασίστηκε ότι δεν είναι εύλογο να παραχθεί κώδικας που ικανοποιεί τις απαιτήσεις της ομάδας.

\marginnote{
	\href{https://gitlab.com/acubesat/obc/ecss-services}{Σύνδεσμος για το αποθετήριο των \ac{ECSS} Services}
}
Ευτυχώς, κατά της διάρκεια της ανάπτυξης του λογισμικού που υλοποιεί τα \ac{ECSS} Services, δημιουργήθηκε η κλάση \texttt{Message}. Η βιβλιογραφία των \ac{ECSS} Services που αναπτύχθηκαν από την ομάδα αναφέρει ότι: 

\par \marginnote{\href{https://acubesat.gitlab.io/obc/ecss-services/docs/}{Σύνδεσμος για τη βιβλιογραφία των \ac{ECSS} Services από την ομάδα}}\textit{Το Message είναι ένα από τα δομικά στοιχεία της υλοποίησης των ECSS Services. Αυτή η κλάση αναπαριστά ένα μήνυμα τηλεμετρίας ή τηλε-εντολής. Το Message είναι η απλούστερη μονάδα πληροφοριών που μεταφέρεται μεταξύ του δορυφόρου και του σταθμού βάσης. Ένα Μήνυμα περιέχει τα δεδομένα του σε μορφή δυαδικής συμβολοσειράς, σε συνδυασμό με ορισμένες βασικές πληροφορίες της κεφαλίδας.}

\par Στην υλοποίηση της κλάσης, η ομάδα επέλεξε το πεδίο δεδομένων του μηνύματος να αναπαριστάται από έναν πίνακα μεταβλητών τύπου \mintinline{c++}|uint8_t|, για τους ίδιους λόγους που αναφέρθηκαν παραπάνω. Η ομάδα επίσης υλοποίησε συναρτήσεις που γράφουν και διαβάζουν μεταβλητές οποιουδήποτε μεγέθους στο πεδίο δεδομένων της κλάσης Message. Για αυτή την ευκολία, αποφασίστηκε να χρησιμοποιηθεί η δυνατότητα αντικειμενοστραφούς κληρονομικότητας στη C++ και να δημιουργηθεί η κλάση TPMessage από την Message.

Όπως αναφέρεται παραπάνω, η κλάση Message παρέχει μεθόδους που διευκολύνουν την ενσωμάτωση και την ανάγνωση μεταβλητών πολλών τύπων, παρά την εσωτερική δομή της κλάσης. Στο παράδειγμα παρακάτω φαίνεται ο τρόπος με τον οποίο αποθηκεύουμε και διαβάζουμε μεταβλητές στη κλάση.

\begin{figure*}
	\inputminted{cpp}{code/examples/ecss-message-usage.cpp}
	\label{code:ecss-message-usage}
	\caption[Παράδειγμα χρήσης της κλάσης Message]{Παράδειγμα χρήσης της κλάσης Message. Η κλάση αυτή παρέχει μεθόδους για την εισαγωγή και την ανάγνωση μεταβλητών οποιουδήποτε μεγέθους στο πεδίο δεδομένων της κλάσης}
\end{figure*}

Η κλάση TPMessage επίσης προσφέρει συναρτήσεις που κωδικοποιούν και αποκωδικοποιούν το πεδίο αναγνωριστικού αποστολέα (\ac{ID}) ενός \ac{CAN-TP} μηνύματος και τα κατάλληλα πεδία που αποθηκεύουν αυτή την πληροφορία. Ως παράγωγη της Message, η κλάση TPMessage περιέχει όλα τα πεδία του γονέα. Επειδή η κλάση Message δημιουργήθηκε εξειδικευμένα για την υλοποίηση των \ac{ECSS} Services, περιέχει πολλά πεδία πέρα των δεδομένων που αφορούν μεταδεδομένα των μηνυμάτων. Ορισμένα από αυτά αναφέρονται στον τύπο της υπηρεσίας στην οποία αναφέρεται το Message και εάν αυτό είναι τηλεμετρία ή τηλε-εντολή. Εφ'όσον αυτά τα πεδία δεν έχουν κάποια σημασία στο σκοπό ενός TPMessage, έχει σημειωθεί ότι η ομάδα πρέπει να τροποποιήσει κατάλληλα στο μέλλον την δομή ενός Message ώστε να αποφευχθούν είτε μελλοντικά λάθη κατανόησης, είτε η σπατάλη μνήμης από τους περιορισμένους πόρους του δορυφόρου. 

Για την κάλυψη των αναγκών της αποστολής είναι απαραίτητη η ανάπτυξη ενός πρωτοκόλλου για την πακετοποίηση και την μεταφορά μηνυμάτων των οποίων το μέγεθος ξεπερνά τα 64-byte. Με βάση το πρωτόκολλο \ac{CAN-TP} \dualcite{iso157652016}, υλοποιήθηκε ένας μηχανισμός που δέχεται μηνύματα ανεξαρτήτου μεγέθους (με πραγματικό όριο τα 1024-byte λόγω περιορισμών μνήμης) και τα χωρίζει σε πακέτα των 64-byte όταν αυτό κρίνεται απαραίτητο. Για την μεταφορά αυτών των μηνυμάτων, το TP μήνυμα ενθυλακώνεται σε ένα ή περισσότερα μηνύματα \ac{CAN} (ή αλλιώς Frames) τα οποία μεταφέρονται στο δίαυλο.

Στο πρωτόκολλο \ac{CAN-TP} υπάρχουν τέσσερις τύποι μηνυμάτων οι οποίοι είναι:

\begin{itemize}
	\item \textbf{Single Frame}: \begin{marginfigure}
		\includegraphics[width=1\textwidth]{media/diagrams/tp-messages/single-message-first-byte.pdf}
		\label{fig:tp-single-frame-first-byte}
		\caption{Το πρώτο byte ενός Single TP Frame}
	\end{marginfigure} Το \ac{CAN-TP} μήνυμα περιέχεται σε ένα μόνο Frame. Το πρώτο byte περιέχει τον συνδυασμό του αναγνωριστικού ενός Single Frame μηνύματος και το μέγεθος των δεδομένων του. Τα επόμενα 63 bytes περιέχουν τα δεδομένα του.
	\item \textbf{First Frame}: \begin{marginfigure}
		\centering
		\includegraphics{diagrams/tp-messages/first-message-first-byte.pdf}
		\label{fig:tp-first-frame-first-byte}
		\caption{Δομή του πρώτου byte ενός First Frame μηνύματος}
		\goodbreak
		\includegraphics{diagrams/tp-messages/first-message-second-byte.pdf}
		\label{fig:tp-first-frame-second-byte}
		\caption{Δομή του δεύτερου byte ενός First Frame μηνύματος}
	\end{marginfigure} Το \ac{CAN-TP} μήνυμα ξεκινά με αυτό το Frame. Η διαφοροποίηση του First Frame από τα επόμενα είναι σημαντική καθώς με την λήψη του First Frame εκκαθαρίζεται η ουρά εισερχόμενων μηνυμάτων τύπου \ac{CAN-TP}. Η εκκαθάριση είναι απαραίτητη καθώς τα μηνύματα συγχωνεύονται σε ένα αντικείμενο τύπου \mintinline{c++}|TPMessage|, συνενώνοντας τα ενθυλακωμένα δεδομένα κάθε μηνύματος με βάση τη θέση τους στην ουρά. Εάν στην ουρά υπάρχουν ήδη μηνύματα που δεν σχετίζονται με το εισερχόμενο, αυτό θα οδηγήσει σε απροσδιόριστη συμπεριφορά. Παραπάνω ανάλυση του τομέα με πιθανές λύσεις δίνεται σε επόμενη ενότητα. Το πρώτο byte περιέχει τον συνδυασμό του αναγνωριστικού ενός First Frame και τον αριθμό των μηνυμάτων που απαρτίζουν ολόκληρο το \ac{CAN-TP} μήνυμα. Τα υπόλοιπα 63 bytes περιέχουν τα δεδομένα του.
	\item \textbf{Consecutive Frame}: \begin{marginfigure}
		\centering
		\includegraphics{diagrams/tp-messages/consecutive-message-first-byte.pdf}
		\label{fig:tp-consecutive-frame-first-byte}
		\caption{Δομή του πρώτου byte ενός Consecutive Frame μηνύματος}
	\end{marginfigure} Το \ac{CAN-TP} μήνυμα περιέχεται σε ένα σύνολο από Consecutive Frames και αυτά ακολουθούν το First Frame. Το πρώτο byte περιέχει τον συνδυασμό του αναγνωριστικού ενός Consecutive Frame και την θέση του στην ουρά των μηνυμάτων. Τα υπόλοιπα 63 bytes περιέχουν τα δεδομένα του.
	\item \textbf{Final Frame}: \begin{marginfigure}
		\centering
		\includegraphics{diagrams/tp-messages/final-message-first-byte.pdf}
		\label{fig:tp-final-frame-first-byte}
		\caption{Δομή του πρώτου byte ενός Final Frame μηνύματος}
	\end{marginfigure} Το \ac{CAN-TP} μήνυμα τελειώνει με αυτό το Frame. Παρόλο που είναι δυνατό να υπολογίσουμε αν το \ac{CAN-TP} μήνυμα έχει ληφθεί ολόκληρο με βάση τον αριθμό των Consecutive Frame που έχουμε δεχτεί, η χρήση του Final Frame διευκολύνει την αναγνωσιμότητα του κώδικα και προσφέρει ταχύτητα. Το επίπεδο του Driver εκτελεί την επεξεργασία της ουράς των μηνυμάτων μόλις δεχτεί ένα Frame με αυτό το byte, χωρίς να χρειαστεί η αποθήκευση και ανάγνωση του αριθμού μηνυμάτων στην ουρά. 
\end{itemize}

\FloatBarrier
Η παραπάνω διαδικασία έχει φανεί αξιόπιστη σε δοκιμές με τρείς κόμβους στο δίκτυο, παρά την απουσία μηχανισμών εντοπισμού και αποκατάστασης σφαλμάτων. Το παραπάνω φαινόμενο είναι δυνατό λόγω της αυτόματης προτεραιότητας στον δίαυλο που εξασφαλίζεται από το πρωτόκολλο. Επειδή η τοποθέτηση μηνυμάτων στην θυρίδα αποστολής σε επίπεδο κώδικα γίνεται σε βρόγχο με ελάχιστη υπολογιστική πολυπλοκότητα μπορούμε να θεωρήσουμε ότι γίνεται αστραπιαία. Στη συνέχεια, ο συνδυασμός του περιφερειακού με τον transceiver του κόμβου θα αποστείλουν τα μηνύματα στο δίαυλο σειριακά. Το αναγνωριστικό ενός \ac{CAN-TP} μηνύματος, όπως ορίστηκε από την ομάδα, περιέχει το αναγνωριστικό του αποστολέα στα περισσότερο-σημαντικά bit. Ως αποτέλεσμα ακόμα και σε συνθήκες υψηλού φόρτου στο δίαυλο τα μηνύματα από ένα κόμβο με υψηλή προτεραιότητα, όπως το \ac{OBC}, θα μεταδίδονται σειριακά χωρίς παύση για μετάδοση από άλλο κόμβο. 

\clearpage
\section{Λειτουργία του Gatekeeper}
\label{sec:gatekeeper}

Σε περίπλοκα ενσωματωμένα συστήματα που χρησιμοποιούν το FreeRTOS συνιστάται η υλοποίηση των Gatekeeper Task. Κάθε περιφερειακό απαιτεί το δικό του Gatekeeper Task. Ο σκοπός του Task είναι η διασφάλιση των συναλλαγών με το περιφερειακό, και αυτό επιτυγχάνεται με την αποκλειστική πρόσβαση του Task σε αυτό. \marginnote{
	Για περισσότερες πληροφορίες, δείτε την ενότητα 7.4 του \cite{FreeRTOSGuide}
} Η ομάδα έχει ακολουθήσει αυτή την πρακτική σε όλα τα περιφερειακά που χρησιμοποιούνται στο λογισμικό του δορυφόρου έως σήμερα, συμπεριλαμβανομένου του περιφερειακού για το \ac{CAN}. Ως εκ τούτου, κάθε διεργασία που απαιτεί την αποστολή δεδομένων μέσω \ac{CAN} χρησιμοποιεί τις συναρτήσεις του CANGatekeeperTask. Η υλοποίηση χρησιμοποιεί δύο στατικά εκχωρημένες ουρές του FreeRTOS. Οι ουρές κρατούν αντικείμενα τύπου Frame, τα οποία διατηρούν πληροφορίες για το αναγνωριστικό (\ac{ID}) και τα δεδομένα ενός μηνύματος. Όπως αναφέρθηκε στην \Cref{sec:environment}, η φύση της ουράς είναι \ac{FIFO}. Μία μέθοδος για παράκαμψη της ουράς σε περίπτωση σημαντικών μηνυμάτων συζητήθηκε, όμως απορρίφθηκε λόγω της πολυπλοκότητας που θα προσέφερε στον κώδικα. Η συμπεριφορά στην περίπτωση που η ουρά είναι ήδη γεμάτη οδηγεί στην απώλεια εξερχομένων μηνυμάτων, κάτι που δεν θεωρείται αποδεκτό στο πλαίσιο του πειράματος. Η ομάδα θα αναλύσει την ορθότερη μέθοδο για την αντιμετώπιση του προβλήματος στο μέλλον, καθώς ο φόρτος στο δίαυλο δεν είναι υψηλός ακόμα ώστε να δημιουργηθεί πρόβλημα.

\begin{figure}
	\centering
	\includegraphics[width=0.9\linewidth]{media/images/clion-queues.pdf}
	\label{fig:clion-queues}
	\caption[Απεικόνιση των ουρών του FreeRTOS στο CLion]{Απεικόνιση των ουρών του FreeRTOS στο CLion}
\end{figure}

\par Η χρήση ουρών από το FreeRTOS κατέληξε εξαιρετικά βολική λόγω της ενσωμάτωσης της στη διεπαφή του ολοκληρωμένου προγράμματος ανάπτυξης (\acs{IDE}) που χρησιμοποείται, το CLion. Όπως ανφέρθηκε παραπάνω, χρησιμοποιώντας δύο εντολές στον κώδικα, το CLion δύναται να διαβάσει τα περιεχόμενα της ουράς ανά πάσα στιγμή και να τα εμφανίσει στο μενού αποσφαλμάτωσης κώδικα. Η λειτουργία αυτή φάνηκε ιδιαίτερα χρήσιμη κατά τη διάρκεια της ανάπτυξης του λογισμικού του δορυφόρου και κατέληξε να χρησιμοποείται σε όλες τις αντίστοιχες ουρές Gatekeeper του δορυφόρου. Η παραπάνω λειτουργία φαίνεται στο \Cref{fig:clion-queues}.

Όπως φαίνεται στο \Cref{code:gatekeeper-execute}, το CANGatekeeperTask είναι εξίσου υπεύθυνο για την διαχείριση των ρυθμίσεων του περιφερειακού σε χαμηλότερο επίπεδο. Με κάθε εκτέλεση, έχει δύο αρμοδιότητες. Αρχικά, ρυθμίζει τις εισόδους \texttt{CAN\_SILENT} των transceivers. \marginnote{Η ρύθμιση \texttt{CAN\_SILENT} γίνεται με τη χρήση GPIO Pin από τον μικροελεγκτή} Οι \ac{CAN} Transceivers έχουν τη δυνατότητα να τεθούν σε \textit{αθόρυβη} λειτουργία, στην οποία απαγορεύεται να στέλνουν μηνύματα στο δίαυλο. Σε αυτή τη λειτουργία επιτρέπεται μόνο να απαντούν σε μηνύματα με την αναγνώριση μηνυμάτων (ACK), όταν αυτό κρίνεται απαραίτητο. Προς το παρόν, όλοι οι κόμβοι του δικτύου απενεργοποιούν τη λειτουργία, καθώς όλα τα υποσυστήματα συμμετέχουν στο δίαυλο. Μελλοντικά, κατά την ανάπτυξη του FlatSat, η ομάδα εξετάζει την συμπερίληψη μίας εξωτερικής πλακέτας για την αναγνώριση σφαλμάτων στο δίαυλο. Για να ελαχιστοποιηθεί η επιρροή της πλακέτας στο σύστημα, αυτή θα τεθεί στην αθόρυβη λειτουργία της με την παραπάνω ρύθμιση. \marginnote{
	Η λειτουργία των \ac{LCL} αναλύεται στο \Cref{sec:obc-adcs-board}
} Η δεύτερη αρμοδιότητα του CANGatekeeperTask είναι να αρχικοποιεί τα κυκλώματα \ac{LCL} που χρησιμοποιούνται στο \ac{OBC}/\ac{ADCS} Board. 

Τέλος, το CANGatekeeperTask εκτελεί και το βασικό του ρόλο, να επιμελείται την πρόσβαση στο περιφερειακό του \ac{CAN}. Οποιαδήποτε άλλη διεργασία που σκοπεύει να στείλει μηνύματα στο δίαυλο χρησιμοποιεί τις ρουτίνες του CANGatekeeperTask, προσθέτοντας τα μηνύματα προς αποστολή στην ουρά εξερχομένων. Με τη σειρά του, το CANGatekeeperTask στέλνει αυτά τα μηνύματα όταν έρθει η σειρά του με βάση την προτεραιότητα που έχει οριστεί στον τεμαχισμό χρόνου από το λειτουργικό σύστημα (FreeRTOS).

\begin{figure}
	\inputminted{c++}{code/examples/gatekeeper-execute.cpp}
	\label{code:gatekeeper-execute}
	\caption[Η συνάρτηση \mintinline{c++}|execute()| του CANGatekeeperTask]{Η συνάρτηση \mintinline{c++}|execute()| του CANGatekeeperTask}
\end{figure}

Η συνάρτηση \mintinline{c++}|send()| του CANGatekeeperTask στο \Cref{code:gatekeeper-send} χρησιμοποιεί όλες τις τεχνικές που ενδείκνυνται από το FreeRTOS για την εξασφάλιση της ασφαλούς λειτουργίας της. Το παράδειγμα της συνάρτησης \mintinline{c++}|send()| εμφανίζεται παρακάτω. Η συνάρτηση εξασφαλίζει την σωστή μετάβαση στην επόμενη διεργασία χρησιμοποιώντας τις γραμμές 4 έως 11. Επειδή η συνάρτηση συχνά καλείται μέσα από \ac{ISR}, είναι σημαντικό να δοθεί προτεραιότητα σε διεργασίες που το απαιτούν, προτού τελειώσει η ρουτίνα. Ο δεύτερος τομέας στον οποίο δίνεται έμφαση είναι η ουρά εξερχομένων, η οποία εκτυπώνει μήνυμα σφάλματος όταν η ουρά είναι πλήρης. Το μήνυμα που προκαλεί το σφάλμα προς το παρόν χάνεται, και η ομάδα θα συζητήσει στο μέλλον την ορθότερη τακτική αντιμετώπισης βλαβών.

\begin{figure*}
	\inputminted{c++}{code/examples/gatekeeper-send.cpp}
	\label{code:gatekeeper-send}
	\caption[Η συνάρτηση \mintinline{c++}|send()| του CANGatekeeperTask]{Η συνάρτηση \mintinline{c++}|send()| του CANGatekeeperTask}
\end{figure*}
\clearpage

\section{Διαφοροποίηση στα \ac{CAN-TP} και non-\ac{CAN-TP} μηνύματα}

Η διαφοροποίηση μεταξύ των μηνυμάτων μορφής \ac{CAN-TP} και μή γίνεται με χρήση του αναγνωριστικού τους. Μία σημαντική λεπτομέρεια για την απόδοση της υλοποίησης σε χρόνο επεξεργαστή και χρήση μνήμης είναι αυτή η διαφοροποίηση να γίνεται στο χαμηλότερο δυνατό επίπεδο. Σχεδόν κάθε περιφερειακό \ac{CAN} σε μικροελεγκτή έχει την δυνατότητα ορισμού κάποιων \textit{φίλτρων}, που καθοδηγούν τα μηνύματα στη σωστή ουρά \ac{FIFO} ανάλογα με το αναγνωριστικό τους. Μία μέθοδος ρύθμισης αυτών των φίλτρων απαιτεί από τον χρήστη να ορίσει ένα εύρος τιμών για το αναγνωριστικό του μηνύματος, όπως και ένα προορισμό. Όταν ένα εισερχόμενο μήνυμα φέρει αναγνωριστικό που βρίσκεται μέσα στο ορισμένο εύρος, το μήνυμα τροφοδοτείται στην αντίστοιχη θύρα εισόδου. Το στιγμιότυπο στο σχήμα \ref{mplab-filters} δείχνει τις επιλογές ρύθμισης φίλτρων για τον μικροελεγκτή SAMV71 στο λογισμικό MPLAB X \acs{IDE}. Όπως αναφέρθηκε προηγουμένως, τα μηνύματα που αφορούν διαδικασίες \ac{CAN-TP} χρησιμοποιούν ειδική μορφή στο αναγνωριστικό τους. Σε επίπεδο bit το αναγνωριστικό ξεκινά με τον συνδυασμό $\textbf{0b0111}0000000$, και τα υπόλοιπα δεδομένα προστίθενται με διαδικασίες bitwise-OR στις αντίστοιχες θέσεις. Το πλεονέκτημα αυτής της υλοποίησης είναι ότι μπορούμε να ξεχωρίσουμε τα μηνύματα \ac{CAN-TP}, αφού βρούμε τα άνω και κάτω όρια της τιμής του \ac{ID}. Στην περίπτωση που έχουμε παντού άσσους θα έχουμε:

\begin{marginfigure}
	\includegraphics[width=1\linewidth]{media/diagrams/tp-message-id.pdf}
	\label{fig:tp-message-id}
	\caption{Μορφή του αναγνωριστικού ενός \ac{CAN-TP} μηνύματος}
	\goodbreak
	\includegraphics[width=1\linewidth]{media/images/mplab-filters.png}
	\label{mplab-filters}
	\caption{Η ρύθμιση των φίλτρων στα μηνύματα εισόδου του \ac{CAN}, από το MPLAB X \acs{IDE}}
\end{marginfigure}

\begin{equation}
\textbf{0b0111}`111`111`1 = 0x3FF
\end{equation}

και στην περίπτωση που έχουμε παντού μηδενικά θα έχουμε:
\begin{equation}
\textbf{0b0111}`000`000`0 = 0x300
\end{equation}

Με αυτή τη πληροφορία, μπορούμε πλέον να ορίσουμε το φίλτρο που θα οδηγήσει τα μηνύματα που δεν αφορούν \ac{CAN-TP} δεδομένα. Ο μικροελεγκτής ATSAMV71Q21B προσφέρει τρία διαθέσιμα \textit{μονοπάτια} για τα εισερχόμενα μηνύματα. Δύο από αυτά είναι ουρές τύπου FIFO με ονόματα \texttt{RX-FIFO-0} και \texttt{RX-FIFO-1}. Η τρίτη επιλογή ονομάζεται Message Buffer και χρησιμοποιεί μία θυρίδα για κάθε ορισμένο  και μοναδικό αναγνωριστικό μηνύματος. Η λειτουργία του Message Buffer είναι ιδιαίτερα βολική εάν έχουμε την ανάγκη να αντιδράσουμε σε ένα μήνυμα με συγκεκριμένο αναγνωριστικό με ξεχωριστό τρόπο, ή με μεγαλύτερη προτεραιότητα. Οι ανάγκες της αποστολής δεν απαιτούν τέτοια λειτουργία. Προς το παρόν, στην υλοποίηση χρησιμοποιούνται αποκλειστικά οι δύο ουρές τύπου \ac{FIFO}. Στην ουρά με όνομα \texttt{RX-FIFO-0} δρομολογούνται τα μηνύματα τύπου \ac{CAN-TP} και στην ουρά με όνομα \texttt{RX-FIFO-1} δρομολογούνται τα υπόλοιπα.

\marginnote{Η λειτουργία Message Buffer μπορεί να χρησιμοποιηθεί για τον συγχρονισμό των κόμβων στο δίαυλο, καθώς τα μηνύματα που οδηγούνται στο Message Buffer έχουν αυστηρά ορισμένο αναγνωριστικό και μπορούν να παρακάμψουν την ουρά \ac{FIFO}. Η λειτουργία αυτή δεν χρησιμοποιήθηκε στο σχεδιασμό του συστήματος, όμως η ομάδα εξετάζει την υλοποίησή της.} 

Με τα μηνύματα αυτόματα χωρισμένα, είναι εύκολο πλέον να ορίσουμε τις ρουτίνες που εκτελούνται στο μηχανισμό interrupt για την λήψη μηνυμάτων \ac{CAN}. Δημιουργήθηκαν δύο συναρτήσεις οι οποίες αρχικά λαμβάνουν τα μηνύματα από την εσωτερική \ac{RAM} που χρησιμοποιεί το περιφερειακό. Οι συναρτήσεις διαφέρουν με βάση το αν λαμβάνουν μηνύματα τύπου \ac{CAN-TP} ή όχι, ώστε να επεξεργαστούν κατάλληλα τα δεδομένα. Στο \Cref{code:driver-tp-message-receiver} παρουσιάζεται η πρώτη συνάρτηση, η οποία χρησιμοποιείται για τα μηνύματα τύπου \ac{CAN-TP} και αρχικά αναλύει τον τύπο του μηνύματος. Εάν αυτό αποτελεί μέρος μεγαλύτερου μηνύματος αυτό  προστίθεται στην ουρά εισερχόμενων μηνυμάτων που αναφέρθηκε παραπάνω. Εάν είναι αυτόνομο ή εάν είναι το τέλος ενός \ac{CAN-TP} μηνύματος πολλαπλών κομματιών, εκτελείται η διαδικασία επανένωσης και ανάγνωσης του μηνύματος. Ο κώδικας που εκτελεί την παρακάτω διαδικασία φαίνεται παρακάτω. Να σημειωθεί ότι η παρακάτω συνάρτηση, όπως και αυτή που προορίζεται για μη-\ac{CAN-TP} μηνύματα είναι ορισμένες δύο φορές. Η μοναδική διαφορά στην υλοποίηση είναι η σωστή κλήση συνάρτησης από το περιφερειακό για την ανάγνωση ενός μηνύματος. Η δομή που δόθηκε από τον κατασκευαστή Microchip δεν επιτρέπει μία πιο κομψή μέθοδο, καθώς τα ορίσματα της συνάρτησης είναι αυστηρώς προκαθορισμένα. Η ορθότερη μέθοδος για τον διαχωρισμό ήταν δύο παραπλήσιες συναρτήσεις.

\begin{figure*}
	\inputminted{c++}{code/examples/driver-tp-message-receiver.cpp}
	\label{code:driver-tp-message-receiver}
	\caption[Η συνάρτηση που λαμβάνει μηνύματα τύπου \ac{CAN-TP}]{Παράδειγμα κώδικα από το αρχείο Driver.cpp όπου παρουσιάζεται η συνάρτηση που λαμβάνει μηνύματα τύπου \ac{CAN-TP}}
\end{figure*}
\FloatBarrier

Στις γραμμές 13 και 20 στο \Cref{code:driver-tp-message-receiver} φαίνεται ο μηχανισμός αναγνώρισης μηνύματος στο πρωτόκολλο TP με βάση τα δύο αρχικά bit του πρώτου byte κάθε μηνύματος. Τα υπόλοιπα bit συμβολίζουν το μέγεθος του μηνύματος, όμως η συνάρτηση σε αυτό το επίπεδο κώδικα δεν έχει σκοπό να τα χρησιμοποιήσει. Σε περίπτωση που το μήνυμα είναι μέρος ενός ευρύτερου συνόλου μηνυμάτων, αυτά ακολουθούν τη διαδικασία ενσωμάτωσης στην ουρά, έως ότου βρεθεί το μήνυμα με τύπο \texttt{Final} στο πρωτόκολλο TP. Σε περίπτωση που το μήνυμα είναι αυτόνομο, δηλαδή τύπου \texttt{Single} στο πρωτόκολλο TP, η ουρά παρακάμπτεται και χρησιμοποιείται η εξειδικευμένη συνάρτηση \mintinline{c++}|ProcessSingleFrame()|.

Στην περίπτωση που το εισερχόμενο μήνυμα δεν είναι τύπου \ac{CAN-TP}, όπως δηλαδή ένα μήνυμα παλμού ή εναλλαγής ενεργού \ac{CAN} Bus, αυτό διαβάζεται κατ'ευθείαν για εξοικονόμηση χρόνου επεξεργαστή μέσα στο \ac{ISR}. Η συνάρτηση που αφορά τα μηνύματα που δεν είναι τύπου \ac{CAN-TP} είναι σαφώς μικρότερη, καθώς δεν υλοποιεί λογική για την διαχείριση πολλών μηνμάτων και παρουσιάζεται στο \Cref{code:driver-non-tp-receiver}. Μετά από ένα βασικό έλεγχο για τη κατάσταση του περιφερειακού, η συνάρτηση μετατρέπει το εισερχόμενο μήνυμα σε μορφή CAN::Frame, όπως χρησιμοποιείται από τα ανώτερα επίπεδα και καλεί τη συνάρτηση επεξεργασίας.

\begin{figure}
	\inputminted{c++}{code/examples/driver-non-tp-receiver.cpp}
	\label{code:driver-non-tp-receiver}
	\caption[Η συνάρτηση που λαμβάνει μηνύματα που δεν είναι τύπου \ac{CAN-TP}]{Παράδειγμα κώδικα από το αρχείο Driver.cpp όπου παρουσιάζεται η συνάρτηση που λαμβάνει μηνύματα που δεν είναι τύπου \ac{CAN-TP}}
\end{figure}
\FloatBarrier

\section{Χρήση δύο ανεξάρτητων διαύλων}

Όπως αναφέρθηκε νωρίτερα, ο νανοδορυφόρος περιλαμβάνει δύο ανεξάρτητους διαύλους για το \ac{CAN} Bus, με σκοπό την ανθεκτικότητα σε αστοχία ενός σημείου. Όπως αναφέρεται στο \dualcite{FMEA}, ο δορυφόρος υλοποιεί τους δύο διαύλους σε μορφή θερμού πλεονασμού και όλα τα υποσυστήματα αναμένουν μηνύματα και από τους δύο διαύλους. Κατά τη διάρκεια της λειτουργίας, τα υποσυστήματα χρησιμοποιούν μία παράμετρο, η οποία απαριθμεί τον ενεργό δίαυλο ανά πάσα χρονική στιγμή. \marginnote{
	Στο πλαίσιο του λογισμικού του δορυφόρου, μία παράμετρος είναι μία μεταβλητή η οποία συνοδεύεται από ένα αναγνωριστικό. Το αναγνωριστικό χρησιμοποιείται για την ταυτοποίηση της παραμέτρου στα μηνύματα μεταξύ των υποσυστημάτων αλλά και κατά τη διάρκεια της επικοινωνίας με το σταθμό βάσης.
} Η παράμετρος αυτή χρησιμοποιείται από τη συνάρτηση \mintinline{c++}|send()| για την επιλογή του διαύλου στον οποίο θα αποσταλλούν τα μηνύματα. Η χρήση της παραμέτρου από το σύνολο της δομής δεδομένων \texttt{AcubeSATParameters} φαίνεται στον παρακάτω κώδικα.

\begin{figure}
	\inputminted{c++}{code/examples/driver-send.cpp}
	\label{code:driver-send}
	\caption{Παράδειγμα κώδικα από το αρχείο Driver.cpp όπου παρουσιάζεται η συνάρτηση \texttt{send}}
\end{figure}

Στις γραμμές 14-18 στο \Cref{code:driver-send} φαίνεται η λογική που αναφέρθηκε σχετικά με την επιλογή του διαύλου. Η αντιστοίχιση της απαρίθμησης \mintinline{c++}|CAN::ActiveBus::Main| στο περιφερειακό \texttt{MCAN0} έγινε καθώς κατά τη διάρκεια της σχεδίασης της πλακέτας \ac{OBC}/\ac{ADCS}, ο δίαυλος που αντιστοιχεί στο δίαυλο \texttt{CAN0} του SpaceCAN \dualcite{SpaceCAN} συνδέθηκε με το περιφερειακό \texttt{MCAN0}. Αντίστοιχα, η απαρίθμηση \mintinline{c++}|CAN::ActiveBus::Redundant| αντιστοιχεί στο περιφερειακό \texttt{MCAN1}, το οποίο αντιστοιχεί στο φυσικό δίαυλο με όνομα \texttt{CAN2}.

Προφανώς, η χρήση των διαύλων σε μορφή θερμού πλεονασμού απαιτεί ένα σύστημα το οποίο θα προσφέρει την κατάλληλη λειτουργικότητα. Για αυτό το σκοπό, το υποσύστημα του \ac{OBC} θα ανταλλάσσει περιοδικά μηνύματα με τα υπόλοιπα υποσυστήματα τα οποία θα χρησιμοποιούνται για τον έλεγχο της υγείας του διαύλου και των υποσυστημάτων. Οι διαδικασίες αυτές εμπεριέχονται στο πλάνο των διαδικασιών εντοπισμού, αναγνώρισης και επιδιόρθωσης σφαλμάτων. Η ομάδα δημιούργησε ένα λεπτομερές πλάνο κατά τη διαδικασία της σχεδίασης του δορυφόρου, το οποίο φαίνεται στο \Cref{fig:fdir}.

\begin{figure*}
	\centering
	\includegraphics[width=1\linewidth]{media/diagrams/fdir-procedures.pdf}
	\label{fig:fdir}
	\caption{Διάγραμμα που περιγράφει τις διαδικασίες \ac{FDIR} στον δίαυλο \ac{CAN}, όπως περιγράφονται από το έγγραφο \cite{FMEA}}
\end{figure*}

Αναλύοντας το πλάνο διαδικασιών \ac{FDIR} στον δίαυλο \ac{CAN}, η ομάδα δημιούργησε ένα σύστημα το οποίο θα εκτελεί τις παρακάτω διαδικασίες, οι οποίες περιγράφονται στο \dualcite{FMEA}:
\begin{itemize}
	\item Η παρακολούθηση του διαύλου πραγματοποιείται με περιοδικά μηνύματα καρδιακών παλμών που αποστέλλονται από όλους τους κόμβους με $T_{HB} = 5$ δευτερόλεπτα.
	\item Το \ac{OBC} αποστέλλει μηνύματα \emph{Ping} σε κάθε κόμβο με την ίδια περίοδο $T_{HB} = 5$ δευτερολέπτων, τα οποία απαιτούν απάντηση \emph{Pong} από τον εκάστοτε κόμβο. Η πρακτική αυτή βοηθά στη διευκρίνιση της αστοχίας στις γραμμές TX ή RX.
	\item Σε περίπτωση που δεν ληφθεί μήνυμα καρδιακού παλμού ή απάντηση σε ένα μήνυμα Ping, από όλους τους κόμβους σε παράθυρο $T_T = 30$ δευτερολέπτων, το \ac{OBC} θεωρεί ότι ο δίαυλος απέτυχε και αποστέλλει μήνυμα \emph{Bus Switchover} το οποίο ανακοινώνει τον πλέον εν λειτουργία δίαυλο. Το μήνυμα αυτό \textbf{μεταδίδεται και στους δύο κόμβους}.
	\item Για να αποφευχθούν περιπτώσεις που κάποιος από τους κόμβους βρίσκεται εκτός συγχρονισμού όσον αφορά τον ενεργό δίαυλο, το \ac{OBC} περιοδικά ανακοινώνει την παράμετρο που περιλαμβάνει την πληροφορία. Η περίοδος αυτής της ανακοίνωσης δεν έχει αποφασιστεί ακόμα.
	\item Oι αστοχίες του \ac{OBC} αντιμετωπίζονται με την ύπαρξη δευτερεύοντος αδρανούς υπεύθυνου \ac{FDIR}, ο οποίος ακούει τα μηνύματα καρδιακών παλμών του \ac{OBC}. Σε περίπτωση που υπάρξει διάρκεια $T_{F2} = 2$ λεπτών χωρίς κανένα καρδιακό παλμό, το \ac{OBC} θεωρείται ότι απέτυχε και το \ac{ADCS} αναλαμβάνει τα καθήκοντα του.
\end{itemize}

Όπως αναφέρεται στο \Cref{chap:usage}, η εργασία αυτή υλοποιεί το σύστημα αποστολής των μηνυμάτων που αφορούν τις παραπάνω διαδικασίες, όπως και μερικούς ελέγχους αποσφαλμάτωσης που αφορούν τον δίαυλο. Στην παρούσα φάση της αποστολής, όμως, η ομάδα δεν επικεντρώνεται ακόμα σε κομμάτια κώδικα που αφορούν διαδικασίες εντοπισμού σφαλμάτων μεταξύ υποσυστημάτων. Η ομάδα δεν έδωσε προτεραιότητα στο παρόν διότι δεν έχουν δημιουργηθεί οι κατάλληλες υποδομές για την επικύρωση αυτού του λογισμικού.

Προς δοκιμή του δευτερεύοντος διαύλου, έχει δημιουργθεί ένα σύστημα που στέλνει τηλε-εντολές οι οποίες ελέγχουν τον ενεργό δίαυλο. Η λειτουργία αυτή αναλύεται περισσότερο στην \Cref{chap:switch-tc}.

\clearpage

\chapter{Πρακτική χρήση}
\label{chap:usage}
Σε αυτή την ενότητα της εργασίας θα παρουσιαστούν οι πρακτικές χρήσεις της και η ενσωμάτωσή της στο σύνολο του πρότζεκτ του AcubeSAT. Ένα σημαντικό επίτευγμα για την παρούσα φάση της αποστολής είναι η λειτουργία του διαύλου στη πλακέτα που στεγάζει τα υποσυστήματα \ac{OBC} και \ac{ADCS}, η οποία σχεδιάστηκε εξ'ολοκλήρου από την ομάδα για χρήση στον νανοδορυφόρο.
\section{Χρήση στο Environmental Testing Campaign του \ac{OBC}/\ac{ADCS} Board}
\subsection{Περιγραφή του \ac{OBC}/\ac{ADCS} Board}
\label{sec:obc-adcs-board}

Το \ac{OBC}/\ac{ADCS} Board, όπως και ο υπόλοιπος νανοδορυφόρος AcubeSAT ακολουθεί το LibreCube Board Specification \dualcite{LibreCubeSpec}. Στο συγκεκριμένο στάνταρ περιγράφονται οι φυσικές ιδιότητες των ηλεκτρονικών πλακετών του δορυφόρου καθώς και οι συνδέσεις μεταξύ τους. Συγκεκριμένα, περιγράφονται τα υλικά και τα μηχανικά χαρακτηριστικά των πλακετών όπως οι διαστάσεις, οι άξονες αναφοράς και οι εγκοπές, ώστε να επιτυγχάνεται συνδεσιμότητα μεταξύ των υποσυστημάτων σε διάταξη στοίβας, σύμφωνα με τις διαστάσεις του προτύπου των CubeSat.

\begin{marginfigure}
	\includegraphics[width=1\linewidth]{images/kicad/transceivers.png}
	\caption[Σχηματικό του \ac{OBC}/\ac{ADCS} Board]{Σχηματικό του \ac{OBC}/\ac{ADCS} Board. Τα στοιχεία U1 και U2 είναι οι \ac{CAN} transceivers που χρησιμοποιούνται για την επικοινωνία μεταξύ των υποσυστημάτων.}
	\label{fig:schematic-transceivers}
\end{marginfigure}

Η πλακέτα τοποθετεί το \ac{OBC} και το \ac{ADCS} σε αντίθετες πλευρές, με κάθε υποσύστημα να διαθέτει δύο \ac{CAN} transceivers. Οι δίαυλοι του \ac{CAN} Bus συνυπάρχουν στον κοννέκτορα PC/104 ο οποίος χρησιμοποιείται ως ένα από τα μέσα τροφοδοσίας των υποσυστημάτων στο νανοδορυφόρο. Στο \Cref{fig:schematic-transceivers} φαίνεται ο κοννέκτορας PC/104 και οι δύο δίαυλοι \ac{CAN} Bus στο σχηματικό του \ac{OBC}/\ac{ADCS} Board. Η σύνδεση των διαύλων μέσα από τον κοννέκτορα PC/104 χρησιμεύει μόνο κατά τη διάρκεια της διαδικασίας κατασκευής και ελέγχου λειτουργίας του νανοδορυφόρου σε επίπεδο υποσυστήματος/συστήματος. Κατά τη διάρκεια της αποστολής, οι δίαυλοι χρησιμοποιούν διαφορετικούς κοννέκτορες που απέχουν $1,7cm$ μεταξύ τους. Ο σκοπός αυτής της επιλογής είναι η αποφυγή της πιθανότητας η βλάβη ενός κοννέκτορα να επηρεάσει και τους δύο διαύλους. 

\begin{figure*}
	\centering
	\includegraphics[width=1\linewidth]{images/obc-adcs-board-obc.png}
	\caption[Ηλεκτρονική απεικόνιση της πλακέτας \ac{OBC}/\ac{ADCS}]{Ηλεκτρονική απεικόνιση της πλακέτας \ac{OBC}/\ac{ADCS}, όπου προβάλλεται η πλευρά που στεγάζει το \ac{OBC}}
	\label{fig:obc-adcs-board-obc}
\end{figure*}

\begin{figure*}
	\centering
	\includegraphics[width=1\linewidth]{images/obc-adcs-board-adcs.png}
	\caption[Ηλεκτρονική απεικόνιση της πλακέτας \ac{OBC}/\ac{ADCS}]{Ηλεκτρονική απεικόνιση της πλακέτας \ac{OBC}/\ac{ADCS}, όπου προβάλλεται η πλευρά που στεγάζει το \ac{ADCS}}
	\label{fig:obc-adcs-board-adcs}
\end{figure*}
Σύμφωνα με το κομμάτι του LibreCube Board Specification που περιγράφει τις ηλεκτρικές συνδέσεις, οι δύο δίαυλοι \ac{CAN} Bus καθιστούν τη μοναδική μέθοδο επικοινωνίας μεταξύ των υποσυστημάτων. Συνεπώς, η δυσλειτουργία των ολοκληρωμένων κυκλωμάτων που πραγματοποιούν αυτή την επικοινωνία θα οδηγήσει σε αποτυχία της αποστολής. Κρίθηκε λοιπόν απαραίτητο, εκτός της στρατηγικής ψυχρού πλεονασμού, να ενσωματωθούν στις in-house πλακέτες τόσο του \ac{OBC}/\ac{ADCS} όσο και του Βιολογικού πειράματος, κυκλώματα προστασίας αυτών των σημαντικών στοιχείων. 

Τα κυκλώματα αυτά ονομάζονται \acl{LCL} και έχουν πρωταρχική λειτουργία την προστασία από \ac{SEL} \dualcite{SpaceRadiationForElectronics}. Tα \ac{SEL} ανήκουν στην κατηγορία των \ac{SEE}, τα οποία προκύπτουν είτε από την κοσμική ακτινοβολία του διαστήματος είτε από ενεργειακά σωματίδια. \begin{marginfigure}
	\centering
	\includegraphics[width=1\linewidth]{images/kicad/lcl.png}
	\caption[Ηλεκτρονική απεικόνιση των \ac{LCL}]{Ηλεκτρονική απεικόνιση των \ac{LCL} της πλακέτας \ac{OBC}/\ac{ADCS}. Στα αριστερά της εικόνας φαίνεται η έξοδος του κυκλώματος προστασίας. Η συγκεκριμένη έξοδος τροφοδοτεί τη μνήμη \ac{NAND}}
	\label{fig:schematic-lcl}
\end{marginfigure} Tα \ac{SEL} οδηγούν ένα ολοκληρωμένο κύκλωμα στο να "τραβήξει" περισσότερο ρεύμα από τη μέγιστη ονομαστική τιμή του, με αποτέλεσμα είτε την διακοπή λειτουργίας, είτε την πρόκληση ζημιάς σε περίπτωση που εκτεθεί για εκτεταμένο χρόνο. Για να αντιμετωπιστεί ένα \ac{SEL}, είναι απαραίτητο να διακοπεί η τροφοδοσία στο κύκλωμα και να τροφοδοτηθεί εκ νέου. Για το λόγο αυτό, ένα \ac{LCL} διακόπτει την τροφοδοσία του ολοκληρωμένου που προστατεύει εάν ανιχνεύσει ένταση ρεύματος μεγαλύτερη από μια γνωστή τιμή κατωφλίου.

Η θεωρία λειτουργίας του \ac{LCL} βασίζεται στην πτώση τάσης που δημιουργεί το ρεύμα τροφοδοσίας του υπό-προστασία ηλεκτρονικού στοιχείου πάνω σε μία αντίσταση μικρής τιμής. Η διαφορική αυτή τιμή της πτώσης τάσης τροφοδοτείται σε ένα κύκλωμα διαφορικού ενισχυτή για να γίνει συγκρίσιμη με την τροφοδοσία του μικροελεγκτή στα 3.3V. Έπειτα, ένας TLC555 timer χρησιμοποιείται σαν συγκριτής μεταξύ της ενισχυμένης τιμής της πτώσης τάσης και μίας τιμής κατωφλίου, η οποία ορίζεται μέσω ενός \ac{DAC} από τον μικροελεγκτή. Αν η ενισχυμένη πτώση τάσης ξεπεράσει το κατώφλι, τότε το \ac{LCL} διακόπτει την τροφοδοσία. Η τιμή κατωφλίου ορίζεται ανάλογα με την ονομαστική τιμή ρεύματος του ηλεκτρονικού στοιχείου υπό προστασία και είναι προσαρμόσιμη και επαναπρογραμματιζόμενη καθ'όλη τη διάρκεια της αποστολής. Για παράδειγμα, ανάλογα με το πλήθος των \ac{SEL} το κατώφλι μπορεί να μεταβληθεί, ενώ μηδενική τιμή κατωφλίου μπορεί να οριστεί για την εξοικονόμηση ενέργειας από το σύστημα.

Περιοδικά, το Task εκτελεί μία διαδικασία εντοπισμού σφαλμάτων, υπολογίζοντας τον χρόνο από την τελευταία επιτυχή αποστολή δεδομένων. \marginnote{
	Η επαναφορά των \ac{LCL} γίνεται με τη χρήση ορισμένων παλμών στα 5KHz χρησιμοποιώντας το περιφερειακό του μικροελεγκτή που ευθύνεται για τη λειτουργία \ac{PWM}.
} Όπως φαίνεται στις γραμμές 13-19 στο \Cref{code:gatekeeper-execute}, εάν ο χρόνος αυτός υπερβεί τα 8 δευτερόλεπτα τα \ac{LCL} επαναφέρονται, μαζί με το εσωτερικό περιφερειακό του επεξεργαστή. Έπειτα, τα μηνύματα που αναμένουν αποστολή στην ουρά εξερχομένων αποστέλλονται. Ο χρόνος επιλέχθηκε πειραματικά. Καθώς ακόμα δεν έχει οριστικοποιηθεί το περιεχόμενο και η περίοδος των περιοδικών μηνυμάτων, η επιλογή αυτή δεν είναι τελική.

\subsection{Σκοπός environmental testing}
Όπως αναφέρθηκε προηγουμένως, ένα σημαντικό επίτευγμα της ομάδας και πιο συγκεκριμένα, του υποσυστήματος του \ac{OBC}, είναι ο σχεδιασμός και η ανάπτυξη της πλακέτας \ac{OBC}/\ac{ADCS} Board. Προσωπικά, συμμετείχα έντονα στην διαδικασία ρύθμισης και ελέγχου της πλακέτας, χάρη στην εξοικείωσή μου με το λογισμικό του δορυφόρου και ολόκληρη την εργασία μου σχετικά με το \ac{CAN} Bus.

Όπως ορίζεται από τις οδηγίες του Ευρωπαϊκού Οργανισμού Διαστήματος (ESA), είναι απαραίτητο όλα τα στοιχεία του δορυφόρου να περάσουν μία σειρά από δοκιμές που θα επιβεβαιώσουν την ορθή λειτουργία τους σε περιβάλλον διαστήματος. Οι δοκιμές αυτές ονομάζονται Environmental Testing και περιλαμβάνονται στην διαδικασία κατασκευής και επιβεβαίωσης του νανοδορυφόρου στο πρόγραμμα \textit{Fly Your Satellite!}.

Καθώς το \ac{OBC}/\ac{ADCS} Board είναι σχεδιασμένο εξ'ολοκλήρου από την ομάδα, η ομάδα κλήθηκε να εκτελέσει αυτές τις δοκιμές στη πλακέτα, προτού αυτή μπορεί να θεωρηθεί ότι αρμόζει σε διαστημική αποστολή. Αρχικά, η πλακέτα τοποθετείται απενεργοποιημένη σε μία μεταλλική πλάκα, όπου διεξάγεται το Vibration Test. Κατά τη διάρκεια της δοκιμής, η πλάκα δονείται με τυχαίο και έντονο τρόπο, προσομοιώνοντας τις δονήσεις και τις δυνάμεις που θα υποστεί η πλακέτα κατά τη διάρκεια της εκτόξευσης \dualcite{OBC_ADCS_EQM_VIBE_TSTP}. Ο σκοπός της δοκιμής αυτής είναι να εξετάσει την αντοχή της πλακέτας, των ολοκληρωμένων κυκλωμάτων πάνω σε αυτή, αλλά και την ποιότητα της εργασίας που έγινε για την συγκόλλησή της. Στην περίπτωση του \ac{OBC}/\ac{ADCS} Board, η δοκιμή αυτή έγινε με επιτυχία, καθώς η πλακέτα δεν υπέστη καμία ζημιά και η λειτουργία της δεν επηρεάστηκε.

Η δεύτερη δοκιμή που διεξάγεται με βάση τις προδιαγραφές της ESA είναι το Thermal Vacuum Test. Κατά τη διάρκεια αυτού του Test, η πλακέτα τοποθετείται στο εσωτερικό του Thermal Vacuum Chamber (TVAC). Ο θάλαμος TVAC μεταφέρεται σε πίεση $10^{-5} hPa$, πίεση που είναι αρκετά χαμηλή ώστε να προσομοιώσει την πίεση στο διάστημα, χωρίς όμως να αποτελέσει τροχοπέδη για την διεξαγωγή του πειράματος σε εύλογο χρονικό διάστημα\dualcite{OBC_ADCS_EQM_TVAC_TSTP}. Η διεξαγωγή πειραμάτων σε χαμηλή πίεση προσομοιώνει τη λειτουργία στο διάστημα και εντοπίζει σφάλματα στην διαδικασία παραγωγής της πλακέτας, όπως Solder Voids. \marginnote{Κατά τη διάρκεια της συγκόλλησης, μπορούν να δημιουργηθούν τρύπες γεμάτες με αέρα μέσα στις ενώσεις των μετάλλων. Όταν η πλακέτα τοποθετηθεί σε κενό αέρος, ο παγιδευμένος αέρας ασκεί δύναμη στις ενώσεις των μετάλλων, όσο προσπαθεί να δραπετεύσει. Αυτή η δύναμη μπορεί να προκαλέσει σπασίματα στις ενώσεις, προκαλώντας σοβαρή ζημιά στην πλακέτα} Στην περίπτωση του \ac{OBC}/\ac{ADCS} Board, η δοκιμή αυτή έγινε με επιτυχία, καθώς η πλακέτα δεν υπέστη καμία ζημιά και η λειτουργία της δεν επηρεάστηκε.

Το δεύτερο κομμάτι του Thermal Vacuum Test αφορά την μελέτη της συμπεριφοράς του συστήματος σε θερμοκρασίες ανάλογες με αυτές που θα συναντήσει κατά τη λειτουργία του σε τροχιά. Όσο η πλακέτα βρίσκεται στο θάλαμο σε κενό αέρος, ο χειριστής μεταβάλλει την θερμοκρασία του θαλάμου έως ότου η πλακέτα να φτάσει στην επιθυμητή θερμοκρασία. Στην περίπτωση του \ac{OBC}/\ac{ADCS} Board, αυτό το εύρος θερμοκρασιών είναι $[-31,+64] ^o C$. Όπως αναφέρεται παρακάτω, το σύστημα εμφάνισε σφάλματα κατά τη διάρκεια της μεταβολής θερμοκρασίας.

Κατά τη διάρκεια του Environmental Testing, είναι σκοπός της ομάδας να επικυρώνονται όσο το δυνατό περισσότερα requirements τα οποία έχουν οριστεί στην διαδικασία σχεδιασμού του δορυφόρου.

Η επικοινωνία μέσω του \ac{CAN} κατά τη διάρκεια της εκστρατείας εξασφαλίζει τη μεταφορά παραμέτρων από το \ac{ADCS} στο \ac{OBC}, επιτρέποντας στο \ac{OBC} να εκτελέσει λειτουργίες Data Housekeeping και Logging. Οι παράμετροι που μεταφέρονται περιλαμβάνουν μετρήσεις από τους αισθητήρες θερμοκρασίας, το μαγνητόμετρο και τα γυροσκόπια. Καθ' όλη τη διάρκεια της εκστρατείας, θα διασφαλίζεται η ομαλή λειτουργία της διαδρομής εκτέλεσης των τηλε-εντολών από τον σταθμό βάσης, όπου εκτελείται ο ρόλος του υποσυστήματος τηλεπικοινωνιών.

\subsection{Χρήση εξωτερικής πλακέτας για μεταφορά Log μηνυμάτων}
Όσο η πλακέτα βρίσκεται στον θάλαμο κενού-θερμότητας (Thermal-Vacuum Chamber), το \ac{OBC}/\ac{ADCS} Board συνδέεται με τον υποστηρικτικό εξοπλισμό με τη βοήθεια ενός καλωδίου που παρέχει τροφοδοσία και μεταφέρει τα απαραίτητα σήματα \ac{UART}, \ac{CAN} και \ac{SWD} για την προετιμασία της πλακέτας και τη διαδικασία που αναφέρθηκε παραπάνω.

Στο πλαίσιο του σχεδιασμού του υποστηρικτικού εξοπλισμού για την εκστρατεία του \ac{OBC}/\ac{ADCS} Environmental Testing, η ομάδα αποφάσισε να χρησιμοποιήσει μια εξωτερική πλακέτα, την SAMV71 Xplained Board. Αυτή η πλακέτα θα συνδέεται μέσω \ac{CAN} με την πλακέτα \ac{OBC}/\ac{ADCS}. 

\begin{figure*}
	\includegraphics[width=1\linewidth]{images/cleanroom-external-board.jpg}
	\label{fig:cleanroom-external-board}
	\caption{Συνδεσμολογία εξωτερικής πλακέτας με το \ac{OBC}/\ac{ADCS} Board}
\end{figure*}
Η πλακέτα SAMV71 Xplained Board, που αποτελεί μέρος του υποστηρικτικού εξοπλισμού για την εκστρατεία \ac{OBC}/\ac{ADCS}, έχει ως σκοπό την προσομοίωση του υποσυστήματος τηλεπικοινωνιών. Αυτό επιτυγχάνεται μέσω της μετατροπής σειριακών δεδομένων από το σταθμό βάσης σε μορφή μηνυμάτων \ac{CAN} και αντίστροφα. Η χρήση αυτής της πλακέτας αποβλέπει στην ελάφρυνση του φόρτου από το μικροελεγκτή του \ac{OBC} και στην καλύτερη προσομοίωση των αρμοδιοτήτων του κατά τη διάρκεια της αποστολής.

Για τη σύνδεση στο δίαυλο, δημιουργήθηκε το Shield \ac{PCB}. Η πλακέτα στεγάζει τους απαραίτητους κονέκτορες και έναν επιπλέον transceiver, καθώς η πλακέτα SAMV71 Xplained περιέχει μόνο ένα. Ο δεύτερος transceiver χρησιμοποιείται για την επικοινωνία στο Redundant Bus.

\begin{marginfigure}
	\includegraphics[width=1\linewidth,angle=180,origin=c]{images/tcan-breakout.jpg}
	\label{fig:tcan-breakout}
	\caption[Συνδεσμολογία TCAN337 Breakout \ac{PCB}]{Η ομάδα παρήγαγε δυό πλακέτες που χρησιμοποιούν το TCAN337 \ac{CAN} Transceiver, για την διάγνωση του προβλήματος με την επικοινωνία στο δίαυλο. Η πλακέτα αυτή παρακάμπτει τον ενσωματωμένο transceiver της πλακέτας SAMV71 Xplained Board.}
\end{marginfigure}
Από τις πρώτες δοκιμές αντιλήφθηκε ότι η λειτουργία δεν ήταν αξιόπιστη και η διάγνωση ήταν ότι οφείλεται στη χρήση διαφορετικών transceivers, των ATA6561 της Microchip σε αντίθεση με τους TCAN337 της Texas Instruments. Παρόλο που και τα δύο μοντέλα ακολουθούν τo στάνταρ ISO11898-1 για το \ac{CAN-FD}, η επικοινωνία χανόταν εύκολα. Δημιουργήθηκε δεύτερη έκδοση που περιέχει τους κατάλληλους transceivers, αλλά και πάλι ο “συγχρονισμός” ήταν ασταθής και έπρεπε να γίνουν reset οι μικρoελεγκτές ταυτόχρονα. Παρά τη χρήση των αντιστάσεων τερματισμού που συνιστώνται από τον κατασκευαστή των TCAN337 \ac{CAN} Transceivers, τα σφάλματα δεν ελαττώθηκαν. Η ομάδα καθήλωσε ότι η πολυπλοκότητα της συνδεσμολογίας είναι υπερβολικά υψηλή για το σκοπό της δοκιμής. Για να μειωθεί η πολυπλοκότητα του εξοπλισμού υποστήριξης, η ομάδα αναθεώρησε το πλάνο και χρησιμοποίησε τη σύνδεση \ac{UART} του \ac{OBC} για την επικοινωνία από και προς τον υπολογιστή.
\subsection{Λειτουργία αυτόματης επαναφοράς μετά από σφάλματα}
Μέσα από την εμπειρία στην επαναφορά χάρη σε παρατεταμένα σφάλματα στο \ac{CAN}, δημιουργήθηκε μια πρώιμη μορφή \ac{FDIR} για την επικοινωνία στο δίαυλο. Αναλύοντας την περιοδικότητα των μηνυμάτων, προγραμματίστηκε η αυτόματη επαναφορά του transceiver και του ενσωματωμένου block περιφερειακού σε περίπτωση που δεν έχει επιτευχθεί επιτυχής αποστολή στα τελευταία 8 δευτερόλεπτα. Η λειτουργία αυτή φάνηκε χρήσιμη σε περιπτώσεις όπου ένα από τα δύο υποσυστήματα έκανε επανεκκίνηση, ενώ το άλλο βρισκόταν στη διαδικασία αποστολής TP μηνυμάτων. Η ουρά εξερχόμενων μηνυμάτων στο περιφερειακό του αποστολέα γέμιζε και η αποστολή μηνυμάτων σταματούσε.

Με την ενσωμάτωση της παραπάνω διαδικασίας διόρθωσης σφαλμάτων, ο μικροελεγκτής κατάφερε να επαναφέρει τη λειτουργία με υψηλή αξιοπιστία. Αυτό επέτρεψε στο σύστημα να συνεχίσει να λειτουργεί αδιάλειπτα για τη διάρκεια του χαρακτηρισμού του γυροσκοπίου του \ac{ADCS}, που διήρκησε μία ώρα. Σε δοκιμές που έγιναν αργότερα, χρησιμοποιοώντας πλακέτες SAMV71 Xplained Board, η διαδικασία αυτή επέτρεψε στο σύστημα να λειτουργεί για περισσότερες από 24 ώρες, χωρίς να χρειαστεί επανεκκίνηση.

\clearpage
\subsection{Εξέταση λειτουργίας εφεδρικού διαύλου κατ'εντολή}
\label{chap:switch-tc}
Κατά την προσπάθεια επικύρωσης των προδιαγραφών του υποσυστήματος, η ομάδα αποφάσισε ότι οι περιβαλλοντικές δοκιμές του \ac{OBC} είναι η κατάλληλη ευκαιρία για την κάλυψη των απαιτήσεων λειτουργίας του \Cref{tab:campaign-requirements}

\begin{table*}
    \centering
    \caption[Απαιτήσεις σχετικές με το \ac{CAN} Bus]{Απαιτήσεις σχετικές με το \ac{CAN} Bus που καλύφθηκαν στο πλαίσιο του Environmental Testing Campaign.}
    \label{tab:campaign-requirements}
    \begin{tabular}{|p{0.45\linewidth}|p{0.45\linewidth}|}
        \hline
        \rowcolor[HTML]{4F5054}
        \multicolumn{2}{|c|}{\color[HTML]{FFFFFF} Requirements} \\ \hline
        \rowcolor[HTML]{F0F0F1} OBC-ADCS-TEST-001 & The ADCS and the OBC MCUs shall receive and execute TCs. \\ \hline
        \rowcolor[HTML]{F0F0F1} OBC-ADCS-TEST-003 & The OBC and ADCS shall be able to exchange messages through the main \ac{CAN} Bus. \\ \hline
        \rowcolor[HTML]{F0F0F1} OBC-ADCS-TEST-004 & The OBC and ADCS shall be able to exchange messages through the redundant \ac{CAN} Bus. \\ \hline
    \end{tabular}
\end{table*}

Για το σκοπό αυτό αποφασίστηκε από την ομάδα να δημιουργηθεί μία υποδομή η οποία θα αλλάζει τον ενεργό δίαυλο, με βάση το περιεχόμενο των τηλε-εντολών που λαμβάνονται από τον υπολογιστή της ομάδας. Για τον έλεγχο του συστήματος, την ανάγνωση των μηνυμάτων τηλεμετρίας και την αποστολή τηλε-εντολών η ομάδα χρησιμοποίησε το \ac{YAMCS}.

\marginnote{
	Το Yamcs είναι ένα ανοιχτού κώδικα λογισμικό για τον έλεγχο διαστημικών αποστολών. Αναπτύχθηκε από την Space Applications Services, μια ανεξάρτητη βελγική εταιρεία. \href{https://yamcs.org/}{Η αρχική σελίδα του Yamcs}
	\goodbreak
	\href{https://gitlab.com/acubesat/obc/ecss-services}{Η υλοποίηση των ecss-services στο GitLab της ομάδας.}
}

Η ομάδα έχει ήδη δημιουργήσει υποδομή για την μεταφορά τηλε-εντολών από τον υπολογιστή προς το μικροελεγκτή με τη χρήση της διεπαφής \ac{UART}. Η μεταφορά τηλε-εντολών από το \ac{YAMCS} ακολουθεί τα πρότυπα των \ac{ECSS} στάνταρ και το λογισμικό του μικροελεγκτή χρησιμοποιεί τις συναρτήσεις των ecss-services για να τις αναγνώσει. Η υλοποίηση των ecss-services περιλαμβάνει δύο πεδία, τα Service και Message Type. Το Service περιγράφει την υπηρεσία που θα εκτελέσει ο μικροελεγκτής, ενώ το Message περιγράφει τον τύπο της εντολής. Για την υλοποίηση της εντολής αποφασίστηκε να δημιουργηθεί ένα νέο \ac{ECSS} Service, το οποίο είναι σχεδιασμένο για να καλύπτει μονάχα την απαιτούμενη τηλε-εντολή. Το έγγραφο των \ac{ECSS} Services \dualcite{ECSS-E-ST-70-41C} αναφέρει ότι όλα τα services που δεν ακολουθούν το στάνταρ πρέπει να έχουν αναγνωριστικό ServiceType πάνω από 128. Με τον παραπάνω περιορισμό, το νέο service χρησιμοποιεί το \mintinline{c++}|const uint8_t ServiceType = 129;|

Η ομάδα έπειτα δημιούργησε μία νέα εντολή στο σύστημα του \ac{YAMCS}, αξιοποιώντας την επεκτασιμότητα του λογισμικού. Η εντολή ορίζει ένα νέο τύπο \ac{ECSS} Service και μία νέα εντολή, η οποία περιλαμβάνει μία απαρίθμηση που αφορά τον πλέον ενεργό δίαυλο. Ο ορισμός της εντολής σε μορφή XML φαίνεται στο \Cref{code:yamcs-xml}

\begin{figure}[h]
	\inputminted{xml}{code/examples/yamcs-129,1.xml}
	\label{code:yamcs-xml}
	\caption[Ορισμός νέας τηλε-εντολής στο \ac{YAMCS}]{Ορισμός της νέας τηλε-εντολής για την επιλογή ενεργού διαύλου στο \ac{YAMCS}}
\end{figure}

\begin{figure}[h]
	\inputminted{xml}{code/examples/yamcs-enumeration.xml}
	\label{code:yamcs-enumeration}
	\caption[Ορισμός της απαρίθμησης στο \ac{YAMCS}]{Ορισμός της νέας απαρίθμησης για την επιλογή ενεργού διαύλου στο \ac{YAMCS}. Πρέπει να δοθεί ιδιαίτερη σημασία στο πεδίο έτσι ώστε να αντιστοιχεί στον κώδικα του μικροελεγκτή.}
\end{figure}

Με τις παραπάνω αλλαγές πλέον η γραφική διεπαφή του \ac{YAMCS} έχει την επιλογή για την αποστολή της τηλε-εντολής \texttt{[129,1]}, που αντιστοιχεί στην επιλογή νέου ενεργού διαύλου για το \ac{CAN} Bus. Για την  παρατήρηση της αλλαγής επιλέχθηκε να χρησιμοποιηθεί ένα περιοδικό μήνυμα, το οποίο δεν αποτελεί κομμάτι του σχεδιασμένου λογισμικού για το δορυφόρο. Το μήνυμα φέρει αναγνωριστικό εκτός του εύρους των γνωστών μηνυμάτων και το πεδίο δεδομένων του αποτελείται από 64 αριθμούς. Το μήνυμα εκτυπώνεται στον υπολογιστή και δείχνει την αλλαγή του ενεργού διαύλου. Σε αυτό παρατηρούμε την εναλλαγή από τον κύριο στο δευτερεύων δίαυλο.

\begin{figure*}
	\includegraphics[width=0.9\linewidth]{images/yamcs-step-1.png}
	\label{fig:yamcs-step-1}
	\caption{Το πρώτο βήμα για την αποστολή της εντολής αλλαγής διαύλου}
\end{figure*}
\begin{figure*}
	\includegraphics[width=0.9\linewidth]{images/yamcs-step-2.png}
	\label{fig:yamcs-step-2}
	\caption{Το δεύτερο βήμα για την αποστολή της εντολής αλλαγής διαύλου}
\end{figure*}

\mintinline{markdown}|50638 [info     ] ADCS     CAN Message: MCAN0 ID : 0 Length : 64 Data : 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16|
\mintinline{markdown}|52941 [info     ] ADCS     CAN Message: MCAN1 ID : 0 Length : 64 Data : 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16|

\subsection{Μεταφορά παραμέτρων και μηνυμάτων τηλε-εντολών/τηλεμετρίας}
Η τροποποίηση του λογισμικού για να καλύψει τις ανάγκες του Environmental Testing Campaign ήταν ευκολότερη χάρη στο application layer. Δημιουργήθηκε ένα περιοδικό task στο FreeRTOS, το οποίο καλούσε μία μόνο συνάρτηση αποστολής παραμέτρων στο \ac{ADCS}. Η λήψη και η αποθήκευση των παραμέτρων από το \ac{OBC} γίνονταν αυτόματα με βάση τον κώδικα που είχε ήδη γραφτεί. Η μεταφορά των τηλε-εντολών υλοποιήθηκε μέσω της δημιουργίας ενός ακόμη "service" στο αποθετήριο των \ac{ECSS} Services. \marginnote{
	Το \ac{ECSS} Application Process \ac{ID} είναι ένας αριθμός που αντιστοιχεί σε κάθε υποσύστημα του δορυφόρου. Ο αριθμός αυτός χρησιμοποιείται για την αναγνώριση των μηνυμάτων που ανταλλάσσονται μεταξύ των υποσυστημάτων.
} Αυτό το service μετέδιδε όλες τις τηλε-εντολές στο ανάλογο υποσύστημα με βάση τo \ac{ECSS} Application Process \ac{ID}.

\begin{marginfigure}
    \includegraphics[width=1\linewidth]{media/diagrams/send-parameters-message.pdf}
    \label{fig:send-parameters-message}
    \caption{Δομή ενός \ac{CAN-TP} μηνύματος που αποστέλλει ένα σύνολο Ν παραμέτρων}
\end{marginfigure}
Για την εξέταση της μεταφοράς παραμέτρων, η ομάδα χρησιμοποίησε τις περιοδικές αναφορές του \ac{OBC}, στις οποίες μεταφέρονται προκαθορισμένες δομές δεδομένων με τις παραμέτρους του μικροελεγκτή. Στην περίπτωση του \ac{ADCS}, η μεταφορά των παραμέτρων γίνεται με την αποστολή ενός μηνύματος \ac{CAN}, το οποίο περιέχει τον αριθμό της παραμέτρου και την τιμή της. Κατά τη λήψη ενός μηνύματος που μεταφέρει παραμέτρους, υλοποιήθηκε ένα σύστημα που εκτυπώνει με λεπτομέρεια τα δεδομένα αυτών για την διευκόλυνση της απεικόνισης των δεδομένων. Σε περίπτωση που το λογισμικό βρίσκεται σε λειτουργία αποσφαλμάτωσης, το \ac{OBC} εκτυπώνει μηνύματα της μορφής:
\mintinline{markdown}|106941 [debug    ] OBC      The value for parameter with ID 1080 was 27.938 and is now 27.03|
\mintinline{markdown}|106941 [debug    ] OBC      The value for parameter with ID 1081 was 28.25 and is now 28.01|
\mintinline{markdown}|106941 [debug    ] OBC      The value for parameter with ID 1208 was 35.527 and is now 34.08|
\mintinline{markdown}|106941 [debug    ] OBC      The value for parameter with ID 1209 was 1.300 and is now 1.400|

\begin{figure*}
	\inputminted{c++}{code/examples/parameter-logging.cpp}
	\label{code:parameter-logging}
	\caption{Η λογική που χρησιμοποιήθηκε για την εκτύπωση των παραμέτρων}
\end{figure*}
Για το σκοπό αυτό, χρησιμοποιήθηκαν συναρτήσεις των ecss-services οι οποίες διαβάζουν το αναγνωριστικό της παραμέτρου, το οποίο έχει σταθερό μήκος. Έπειτα, με βάση τους γνωστούς τύπους των παραμέτρων, διαβάζεται το μήνυμα και γίνεται μετατροπή στον σωστό τύπο. Η λογική που χρησιμοποιήθηκε για την παραπάνω λειτουργία φαίνεται στο \Cref{code:parameter-logging}.

Τέλος, η μεταφορά των log μηνυμάτων γίνεται με μία μόνο κλήση συνάρτησης του Application Layer, όπου ο χρήστης αντικαθιστά τη χρήση του περιφερειακού \ac{UART} με τη συνάρτηση \mintinline{c++}|CAN::sendLogMessage()|.
\subsection{Διακοπή λειτουργίας σε υψηλή θερμοκρασία}
\marginnote{
	Τα αρχικά TCXO αφορούν τον Temperature Compensated Crystal Oscillator - ένας τύπος κρυστάλλου που χρησιμοποιείται για τη δημιουργία σταθερής συχνότητας σε ηλεκτρονικές συσκευές, όπως τα ρολόγια
}

Λόγω παγκοσμίων προβλημάτων στην αλυσίδα εφοδιασμού κατά την παραγωγή της πλακέτας του \ac{OBC}/\ac{ADCS}, χρησιμοποιήθηκαν υποκατάστατα TCXO στα \ac{OBC} και \ac{ADCS}. Τα ρολόγια είχαν τις ίδιες μηχανικές ιδιότητες, ωστόσο λειτουργούσαν στα 16MHz αντί για 12MHz, όπως είχε σχεδιαστεί για τη χρήση στο δορυφόρο. Στη θέση τους, χρησιμοποιήσαμε το ενσωματωμένο κύκλωμα RC του μικροελεγκτή, το οποίο ήταν ρυθμισμένο στα 12MHz. Το κύκλωμα αυτό χρησιμοποιεί μία διάταξη αντίστασης-πυκωντή για να παρέχει παλμούς ρολογιού σε μικρό μέγεθος και μικρό κόστος. Στο TVAC, το κύκλωμα RC προκάλεσε σφάλματα στους μικροελεγκτές της πλακέτας. Η ομάδα αντιλήφθηκε ότι λόγω της αυξημένης θερμοκρασίας μέσα στο θάλαμο, η οποία ξεπέρασε τους $50^o C$, προκλήθηκε ολίσθηση στα ρολόγια των μικροελεγκτών. Η ολίσθηση στα ρολόγια μπορεί να προκαλέσει προβλήματα συγχρονισμού με εξωτερικά περιφερειακά τα οποία έχουν αυστηρές προδιαγραφές χρονισμού, όπως για παράδειγμα οι \ac{CAN} Transceivers ή οι εξωτερικές μνήμες. Τόσο το \ac{OBC} όσο και το \ac{ADCS} σταματούσαν να λειτουργούν επανειλημμένως. Λόγω της ύψιστης σημασίας ακριβούς συγχρονισμού στις χρονικές θυρίδες του \ac{CAN}, η επικοινωνία των υποσυστημάτων ήταν ακόμα πιο αναξιόπιστη από τους μικροελεγκτές.

\subsection{Εφαρμογή λύσης και επικύρωση ορθής λειτουργίας}
Μετά την ανεπιτυχή προσπάθεια επικύρωσης της λειτουργίας του συστήματος σε συνθήκες διαστήματος, η ομάδα κατέληξε στην απόφαση να αντικαταστήσει τα ρολόγια με αυτά που είναι πιο κατάλληλα για τον σκοπό αυτό. Εφ'όσον τα προβλήματα στην αλυσίδα εφοδιασμού είχαν πλέον επιλυθεί η ομάδα απέκτησε τους κρυστάλλους TCXO που θα χρησιμοποιηθούν στα υπόλοιπα μοντέλα, έως και το Flight Model (FM). Η πλακέτα στάλθηκε στην εταιρεία PRISMA Hellas, η οποία είναι η εταιρεία συναρμολόγησης της πλακέτας. Εκεί, οι κρύσταλλοι TCXO αντικαταστάθηκαν με τα νέα μοντέλα, που λειτουργούν στη συχνότητα των 12MHz. Το λογισμικό τροποποιήθηκε κατάλληλα ώστε να χρησιμοποιεί τους καινούργιους κρυστάλλους. Οι δοκιμές για υψηλή θερμοκρασία πραγματοποιήθηκαν στο cleanroom της ομάδας, με τη βοήθεια συμφοιτητών. Για την προσομοίωση του περιβάλλοντος του TVAC χρησιμοποιήθηκε ένας προβολέας που χρησιμοποιεί λάμπα αλογόνου με ισχύ $300W$.

\begin{marginfigure}
	\includegraphics[width=1\linewidth]{images/lamp-heater.jpg}
	\label{fig:lamp-heater}
	\caption{Ο προβολέας που χρησιμοποιήθηκε για την προσομοίωση του περιβάλλοντος του TVAC}
\end{marginfigure}
Η λάμπα αυτή, φωτίζοντας τη πλακέτα από κοντινή απόσταση, αρκεί για να ικανοποιήσει τις απαιτήσεις του πειράματος. Χρησιμοποιώντας τη θερμότητά της, η θερμοκρασία της πλακέτας αυξήθηκε σταδιακά έως τους $55^o C$, όπου ρυθμίζοντας την απόσταση της λάμπας, η ομάδα ρύθμισε την θερμοκρασία της πλακέτας. Χρησιμοποιώντας τον εξοπλισμό και το λογισμικό που αναπτύχθηκε για το Environmental Testing Campaign, η ομάδα είχε ακριβείς μετρήσεις από 4 αισθητήρες θερμοκρασίας που βρίσκονται στην πλακέτα, όπως και ένα thermocouple που ήταν τοποθετημένο στο πλαστικό πακέτο του μικροελεγκτή που στεγάζει το \ac{OBC}. Με αυτή τη δοκιμή, επιβεβαιώθηκε η αξιόπιστη λειτουργία του \ac{CAN} σε υψηλή θερμοκρασία. Οι δύο μικροελεγκτές των \ac{OBC} και \ac{ADCS} αντάλλαζαν συνεχώς μηνύματα ορθής λειτουργίας και μετέφεραν παραμέτρους, όπως τις προαναφερθείσες θερμοκρασίες. Αντιθέτως, οι μικροελεγκτές εξακολούθησαν να σταματούν επανειλημμένως. Η λειτουργία του \ac{CAN} επανερχόταν μετά από κάθε επανεκκίνηση, γεγονός που δείχνει βελτίωση στη λειτουργία του \ac{CAN}. Η ομάδα ερευνά πιθανές λύσεις για το πρόβλημα των μικροελεγκτών, εστιάζοντας στα κυκλώματα τροφοδοσίας και τους χρονισμούς της εξωτερικής μνήμης \ac{MRAM} που χρησιμοποιεί το \ac{OBC}.

\chapter{Συμπεράσματα και Μελλοντική Εργασία}
\label{future-work}
Η εργασία αυτή παρουσίασε μία λειτουργική υλοποίηση του πρωτοκόλλου \ac{CAN} στον μικροελεγκτή του δορυφόρου. Η εργασία αυτή είναι η πρώτη που έχει γίνει στον μικροελεγκτή του δορυφόρου και έθεσε βάσεις που η ομάδα θα ακολουθήσει στην ανάπτυξη των υπόλοιπων λειτουργιών αυτού. Η υλοποίηση αυτή θα χρησιμοποιηθεί για την επικοινωνία των υποσυστημάτων του δορυφόρου κατά την ανάπτυξή του, καθώς και για την επικοινωνία κατά τη διάρκεια της αποστολής.

Στο \Cref{chap:acubesat} παρουσιάστηκε η αποστολή του νανοδορυφόρου AcubeSAT, που αποτελεί την κύρια αφορμή και πλαίσιο συγγραφής της. Συνεχίζοντας, αναλύονται οι αποφάσεις που οδήγησαν στην επιλογή του \ac{CAN} Bus ως διαύλου εύρωστης επικοινωνίας μεταξύ των υποσυστημάτων του νανοδορυφόρου. Το επόμενο κομμάτι αναφέρεται στην λειτουργικότητα, ιστορία και υψηλού-επιπέδου περιγραφή του \ac{CAN} Bus. Το \Cref{chap:design-choices} αναλύει τις επιλογές της ομάδας που αφορούν τις λεπτομέρειες στην υλοποίηση του διαύλου, οι οποίες όρισαν με αυστηρό τρόπο τις προδιαγραφές που καλύπτει η τελική υλοποίηση.

\par Έπειτα, το \Cref{chap:implementation} αναλύει την εργασία μου για την υλοποίηση του διαύλου στο σύστημα μικροελεγκτή-λειτουργικού-λογισμικού που αναπτύχθηκε από την ομάδα. Σε αυτό παρουσιάστηκε η μεθοδολογία που ακολουθήθηκε για την επίλυση περίπλοκων προβλημάτων υπό τους περιορισμούς του ενσωματωμένου περιβάλλοντος. Αναλύθηκαν οι διαδικασίες που απαιτούνται για την ασφαλή διαχείριση μνήμης, την αποδοτική επεξεργασία μηνυμάτων και τις μοντέρνες πρακτικές που χρησιμοποιούνται για την αναγνωσιμότητα και επεκτασιμότητα του λογισμικού. Τέλος, στο \Cref{chap:usage} αναφέρεται η πρακτική εφαρμογή της εργασίας μου στο έως σήμερα υλοποιημένο έργο του πρότζεκτ. Σε αυτό πρωταρχικό ρόλο παίρνει η επικύρωση του \ac{OBC}/\ac{ADCS} \ac{PCB}, τα οποία είναι τα πρώτα υποσυστήματα που διαθέτει η ομάδα για ανάπτυξη.

Η εργασία μου καλύπτει το τρέχον στάδιο του δορυφόρου, καθώς και τα μελλοντικά στάδια του πλάνου \ac{MAIV} \dualcite{MAIVP} (όπως η ενσωμάτωση των υποσυστημάτων στον FlatSat). Ωστόσο, δεν θεωρείται ακόμη "flight ready", όπως και το μεγαλύτερο μέρος του λογισμικού του δορυφόρου. Οι κυριότερες ελλείψεις αφορούν τις \textbf{διαδικασίες \ac{FDIR}} και τις περιπτώσεις που \textbf{δεν ήταν δυνατό να προσομοιωθούν} κατά την εκτέλεση της εργασίας μου στο \ac{CAN}. Συγκεκριμένα, οι πτυχές της υλοποίησης που μπορούν να βελτιωθούν και να αναπτυχθούν είναι οι εξής:

\begin{fullwidth}
	\begin{itemize}
		\item \textbf{Αποστολή και λήψη εικόνων από το επιστμηονικό πείραμα του δορυφόρου}: Η μεταφορά των εικόνων θα αποτελέσει ένα σημαντικό επίτευγμα για την ομάδα, λόγω των απαιτήσεων της υλοποίησης. Καθώς οι εικόνες αυτές υπολογίζεται ότι θα χρησιμοποιούν περίπου 3MB+ αποθηκευτικού χώρου, είναι αδύνατο να χρησιμοποιηθεί η τωρινή υλοποίηση για αυτή τη λειτουργία. Τα μηνύματα μπορεί να αποσταλλούν εκτός σειράς, λόγω των εσωτερικών μηχανισμών αποφυγής σφαλμάτων στο \ac{CAN}. Θα χρειαστεί μηχανισμός καταμέτρησης μηνυμάτων και χρήση checksums για την επικύρωση των δεδομένων. Η ομάδα θα χρησιμοποιήσει ένα συνδυασμό των \ac{ECSS} ST[06] Memory Management, ST[13] Large Packet Transfer και ST[23] File Management services, όταν διαθέσει το ανθρώπινο δυναμικό για την υλοποίηση της λειτουργίας.
		\item \textbf{Βελτίωση της λειτουργίας αποσφαλμάτωσης}: Μήνες μετά την ολοκλήρωση της υλοποίησης, η κατασκευαστική εταιρεία Microchip έχει ανανεώσει τον κώδικα του περιφερειακού ώστε να παρέχει απαριθμημένα (enumerated) \mintinline{c++}|MCAN_ERRORS|, με τρόπο που περιγράφουν το σφάλμα. Γνωρίζοντας πλέον τα πιθανά σφάλματα, η ομάδα έχει την δυνατότητα να τα αντιμετωπίσει με πιο αποτελεσματικό τρόπο.
		\item \textbf{Εξακρίβωση ορθής συμπεριφοράς σε γεμάτες ουρές}: Η ομάδα πρέπει να συζητήσει και να καταλήξει στην ορθή συμπεριφορά του συστήματος όταν πρόκειται να προστεθεί ένα μήνυμα σε μία γεμάτη ουρά εισερχομένων ή/και εξερχομένων. Λαμβάνοντας υπ'όψη την περιοδική φύση των μηνυμάτων θα μπορούσαμε να θεωρήσουμε αποδεκτό το γεγονός να \emph{χάσουμε} κάποιο πακέτο, όμως δεν υπάρχει τρόπος να ξεχωρίσουμε εάν κάποιο πακέτο είναι περιοδικό ή όχι, προτού αυτό περάσει την διαδικασία της επεξεργασίας που ξεκινά με αυτή την ουρά. Η ομάδα θα πρέπει να εξετάσει τις πιθανές λύσεις και να επιλέξει την καταλληλότερη. 
		\item \textbf{Διαχείριση μηνυμάτων \ac{CAN-TP} από πολλαπλούς αποστολείς και τις συγκρούσεις τους}: Τα μηνύματα \ac{CAN-TP}, όπως αναφέρθηκε παραπάνω, είναι δυνατό να αποτελούνται από πολλά μικρότερα Frames, έτσι ώστε να αυξηθεί ο περιορισμός του μέγιστου μεγέθους για ένα μήνυμα από 64-bytes στα 1024-bytes. Κατά τη διάρκεια αυτής της αποστολής όμως αναιρούνται οι ενσωματωμένοι μηχανισμοί του \ac{CAN} Bus για αυτόματη διαχείριση συγκρούσεων. Ως αποτέλεσμα, είναι δυνατό να υπάρξει σύγκρουση κατά τη διάρκεια της αποστολής ενός μηνύματος \ac{CAN-TP}, και τα πακέτα ενός μηνύματος να αναμιχθούν με πακέτα άλλου μηνύματος. Σε αυτή την περίπτωση τα μηνύματα δεν θα είναι πλέον έγκυρα και θα πρέπει να απορριφθούν. Η ομάδα θα πρέπει να εξετάσει την πιθανότητα χρήσης \emph{θυρίδων}, όπου τα μηνύματα από κάθε υποσύστημα θα αποθηκεύονται σε ξεχωριστή ουρά. Μόνο όταν ληφθεί ένα ολοκληρωμένο μήνυμα, θα χρησιμοποιηθεί η αντίστοιχη ουρά για την ανακατασκευή του, ώστε να αποφευχθεί αυτό το σφάλμα.
		\item \textbf{Μετατροπή σε αντικειμενοστραφή Driver}: Η υλοποίηση του \ac{CAN} Driver έγινε με τη χρήση της γλώσσας C++, όμως ο κώδικας που παράγεται από το MPLAB X \ac{IDE} για τη διεπαφή με το περιφερειακό χρησιμοποιεί αποκλειστικά τη γλώσσα C, με όλες τις ιδιότητες και το στυλ γραφής της. Ως αποτέλεσμα, ο \ac{CAN} Driver χρησιμοποιεί ελάχιστες λειτουργίες της C++ που προσφέρουν αναγνωσιμότητα και δυνατότητα επαναχρησιμοποίησης. Η ομάδα θα εξετάσει την εφικτότητα μετατροπής του Driver σε μορφή C++ κλάσης, ώστε να καλύπτονται οι ανάγκες των περιφερειακών MCAN0 και MCAN1 με ελάχιστη διπλοτυπία στον κώδικα.
	\end{itemize}
\end{fullwidth}

%\backmatter
\appendix

\begin{fullwidth}
\bgroup
\printbibliography[heading=bibnumbered,title={Βιβλιογραφία}]
\egroup
\end{fullwidth}

\chapter{Πηγαίος Κώδικας}

\section*{ApplicationLayer.hpp}
\inputminted{cpp}{code/full-files/ApplicationLayer.hpp}
\newpage
\section*{ApplicationLayer.cpp}
\inputminted{cpp}{code/full-files/ApplicationLayer.cpp}
\newpage
\section*{CANGatekeeperTask.hpp}
\inputminted{cpp}{code/full-files/CANGatekeeperTask.hpp}
\newpage
\section*{CANGatekeeperTask.cpp}
\inputminted{cpp}{code/full-files/CANGatekeeperTask.cpp}
\newpage
\section*{CANTestTask.hpp}
\inputminted{cpp}{code/full-files/CANTestTask.hpp}
\newpage
\section*{CANTestTask.cpp}
\inputminted{cpp}{code/full-files/CANTestTask.cpp}
\newpage
\section*{Driver.hpp}
\inputminted{cpp}{code/full-files/Driver.hpp}
\newpage
\section*{Driver.cpp}
\inputminted{cpp}{code/full-files/Driver.cpp}
\newpage
\section*{Frame.hpp}
\inputminted{cpp}{code/full-files/Frame.hpp}
\newpage
\section*{TPMessage.hpp}
\inputminted{cpp}{code/full-files/TPMessage.hpp}
\newpage
\section*{TPProtocol.hpp}
\inputminted{cpp}{code/full-files/TPProtocol.hpp}
\newpage
\section*{TPProtocol.cpp}
\inputminted{cpp}{code/full-files/TPProtocol.cpp}
\newpage
\section*{Definitions.hpp}
\inputminted{cpp}{code/full-files/Definitions.hpp}
\newpage
\section*{EnvironmentalTestingService.hpp}
\inputminted{cpp}{code/full-files/EnvironmentalTestingService.hpp}
\newpage
\section*{EnvironmentalTestingHelper.cpp}
\inputminted{cpp}{code/full-files/EnvironmentalTestingHelper.cpp}
\end{document}