EP3698253A1

EP3698253A1 - System and method for managing program memory on a storage device

Info

Publication number: EP3698253A1
Application number: EP18867427.9A
Authority: EP
Inventors: Lior HAMMER; Gilad Barzilay; Yaron Galula
Original assignee: Argus Cyber Security Ltd
Current assignee: Argus Cyber Security Ltd
Priority date: 2017-10-17
Filing date: 2018-10-17
Publication date: 2020-08-26
Also published as: EP3698253A4; WO2019077607A1

Abstract

A system and a method of managing program memory on a storage device. The method may include: receiving storage block information, including at least one of: storage block size of a storage device and block utilization limit of the storage device; receiving at least one first object file including a plurality of object code segments and a respective plurality of linker placeholders; sparsely stacking the object code segments to produce two or more libraries according to the storage block information; replacing the plurality of linker placeholders with actual addresses of sections of program memory according to the stacking of object code segments; and storing the plurality of object code segments on the storage device according to the actual addresses.

Description

SYSTEM AND METHOD FOR MANAGING PROGRAM MEMORY ON A STORAGE

DEVICE

FIELD OF THE INVENTION

[001] The present invention relates to programmable computing devices. More particularly, the present invention relates to systems and methods for management of program memory storage.

BACKGROUND OF THE INVENTION

[002] Small, low-end embedded devices, that employ minimal computational resources are ubiquitous in almost every aspect of modern life. Internet of Things (IoT) devices with minimal storage capacity, that employ no operating system (OS), or only rudimentary versions thereof are prevalent in both the industrial and private consumption market.

[003] An example for such IoT devices may be elements of automotive, or inter- vehicle networks, that allow internal communication between various components of a vehicle (e.g., air conditioning system, diagnostics, engine, etc.) via Electronic Control Units (ECUs). ECUs normally gets input from sensors (e.g., speed, temperature, pressure, etc.) to be used in its analysis and exchange data among themselves during the normal operation of the vehicle. For example, an engine may need to inform a transmission box what the engine speed is, and the transmission may need to inform other modules when a gear shift occurs. The inter-vehicle network allows exchanging data quickly and reliably, with internal communication between the ECUs.

[004] Software and/or firmware of such embedded devices may be uploaded using Over-The- Air (OTA) programming, where new software, configuration settings, and updating encryption keys may be distributed to various computerized devices. Usually, a central location, such as a dedicated remote server may send an update to a subset of users or embedded end units.

[005] Delta updates are a common method to carry out software updates over the air, occupying minimal memory for each update, in order to reduce bandwidth costs and minimize update time so as to reduce the overall system down-time. Delta updates include sending the difference between an old version of the software (or software image such as an object file, as commonly referred to in the art) and a new (or revised) version of the software image, instead of sending the new software image in its entirety. Once an end unit (e.g., an IoT device) has received the update, a dedicated algorithm may analyze the received partial image and the existing software image and decide what needs to be updated.

[006] Delta update algorithms may require a substantial amount of memory, that may exceed the available memory on the embedded device. For example, a prevalent delta update algorithm called "bsdiff ' normally requires n+m+0(l) bytes of memory, where 'n' is the size of the old software component in bytes, 'm' is the size of the new software component in bytes and 0(1) is a big O notation of a constant, that may depend upon a specific implementation of the algorithm, as known in the art.

[007] While the abovementioned processing requirement may be reasonable for some computerized platforms (e.g., personal computers, smartphones, laptops, etc.) that normally possess considerable memory resources in comparison with the size of update software images, IoT systems in general and automotive ECUs in particular may lack such resources and may require a new approach.

SUMMARY OF THE INVENTION

[008] Embodiments of the present invention may include a system and a method of managing program memory on a storage device. According to some embodiments, the method may include:

receiving storage block information, including at least one of: storage block size of a storage device and block utilization limit of the storage device;

receiving at least one first object file including a plurality of object code segments and a respective plurality of linker placeholders;

sparsely stacking the object code segments to produce two or more libraries according to the storage block information;

replacing the plurality of linker placeholders with actual addresses of sections of program memory according to the stacking of object code segments; and

[009] storing the plurality of object code segments on the storage device according to the actual addresses.

[010] The plurality of object code segments may be associated with respective one or more functions of software modules, and sparsely stacking of object code segments may include selection of object code segments according to the association of the object code segments with the respective functions of software modules.

[Oi l] Embodiments of the method may further include:

attributing a block utilization limit to each software module; and

stacking the object code segments according to the attributed block utilization limit.

[012] Embodiments of the method may further include:

producing a function call graph comprising a plurality of nodes, each representing a specific function associated with an object code segment, and a plurality of edges, each representing a call of one function to another; and

attributing each node of the function call graph a size indicator, representing a storage size of the respective object code segment.

[013] According to some embodiments, selection of object code segments for stacking may include:

a. selecting a group comprising one or more object code segments that are related along branches of the function call graph, such that the cumulative value of the one or more object code segments' size indicator does not surpass the block utilization limit;

b. stacking the group of selected object code segments to produce a library; and c. repeating steps a and b, until all object code segments of the at least one first object file are stacked in libraries.

[014] Embodiments of the method may further include:

receiving at least one second object file comprising at least one object code segment; applying a delta encoding algorithm on the at least one first and second object files to produce a patch file comprising at least one patch object code segment; and

storing the at least one patch object code segment on a block of the program memory storage.

[015] Embodiments of the method may further include maintaining an address table associating each object code segment with a respective storage address on a block of the program memory storage and storing of the patch object code segment may include replacing the storage address of at least one object code segment on the address table with that of the patch object code segment. [016] The method of claim 2, wherein the software modules are associated with one or more abstraction layers, selected from a list comprising a kernel layer, a driver layer and an application layer.

[017] Embodiments of the present invention may include a system for managing program memory on a storage device. The system may include:

a first storage device;

a second, non-transitory memory device, wherein modules of instruction code are stored, and

a processor associated with the second device, and configured to execute the modules of instruction code, whereupon execution of said modules of instruction code, the processor is configured to perform at least one of:

receive storage block information of the first storage device, including at least one of: storage block size of a storage device and block utilization limit of the storage device; receive at least one first object file including a plurality of object code segments and a respective plurality of linker placeholders;

sparsely stack the object code segments to produce two or more libraries according to the storage block information;

replace the plurality of linker placeholders with actual addresses of the sections of program memory according to the stacking of object code segments; and

store the plurality of object code segments on the first storage device according to the actual addresses.

[018] Embodiments of the present invention may include method of managing program memory on a storage device. The method may include:

receiving storage block information pertaining to a storage device;

analyzing at least one instruction code file, to produce a function call graph;

compiling the at least one instruction code file, to produce at least one object file including a plurality of object code segments and a respective plurality of linker placeholders;

sparsely stacking the object code segments to produce two or more libraries according to the storage block information and the function call graph; replacing the plurality of linker placeholders with actual addresses of sections of program memory according to the stacking of object code segments; and

sparsely storing the plurality of object code segments on the storage device according to the actual addresses.

BRIEF DESCRIPTION OF THE DRAWINGS

[019] The subject matter regarded as the invention is particularly pointed out and distinctly claimed in the concluding portion of the specification. The invention, however, both as to organization and method of operation, together with objects, features, and advantages thereof, may best be understood by reference to the following detailed description when read with the accompanying drawings in which:

[020] Fig. 1 is a block diagram, depicting a computing device that may be included within a system for management of program memory storage, according to some embodiments;

[021] Fig. 2 is a block diagram, depicting system for management of program memory storage, according to some embodiments;

[022] Fig. 3 is a schematic block diagram, depicting an example of object code data that may be used by a system for management of program memory storage, according to some embodiments;

[023] Fig. 4 is a block diagram, depicting an example of an implementation of a system for management of program memory storage as part of an inter-vehicle network constellation, according to some embodiments;

[024] Fig. 5A and 5B are block diagrams, depicting two example for utilization of a program memory storage device as part of a system for management of program memory storage, according to some embodiments;

[025] Fig. 6 is a block diagram, depicting an example of a function call graph, which may be included within a system for management of program memory storage, according to some embodiments;

[026] Fig. 7 is a flow diagram, depicting a method of management of program memory storage, according to some embodiments; and

[027] Fig. 8 is a flow diagram, depicting a method of management of program memory storage, according to some embodiments. [028] It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity. Further, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

[029] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be understood by those skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, and components have not been described in detail so as not to obscure the present invention.

[030] Although embodiments of the invention are not limited in this regard, discussions utilizing terms such as, for example, "processing," "computing," "calculating," "determining," "establishing", "analyzing", "checking", or the like, may refer to operation(s) and/or process(es) of a computer, a computing platform, a computing system, or other electronic computing device, that manipulates and/or transforms data represented as physical (e.g., electronic) quantities within the computer's registers and/or memories into other data similarly represented as physical quantities within the computer's registers and/or memories or other information non-transitory storage medium that may store instructions to perform operations and/or processes. Although embodiments of the invention are not limited in this regard, the terms "plurality" and "a plurality" as used herein may include, for example, "multiple" or "two or more". The terms "plurality" or "a plurality" may be used throughout the specification to describe two or more components, devices, elements, units, parameters, or the like. The term set when used herein may include one or more items. Unless explicitly stated, the method embodiments described herein are not constrained to a particular order or sequence. Additionally, some of the described method embodiments or elements thereof can occur or be performed simultaneously, at the same point in time, or concurrently. [031 ] Reference is now made to Fig. 1 , which is a block diagram depicting a computing device 10, which may be included within an embodiment of a system for management of program memory storage, according to some embodiments.

[032] Computing device 10 may include a controller 2 that may be, for example, a central processing unit (CPU) processor, a chip or any suitable computing or computational device, an operating system 3, a memory 4, executable code 5, a storage system 6, input devices 7 and output devices 8. Controller 2 (or one or more controllers or processors, possibly across multiple units or devices) may be configured to carry out methods described herein, and/or to execute or act as the various modules, units, etc. More than one computing device 10 may be included in, and one or more computing devices 10 may act as the components of, a system according to embodiments of the invention.

[033] Operating system 3 may be or may include any code segment (e.g., one similar to executable code 5 described herein) designed and/or configured to perform tasks involving coordination, scheduling, arbitration, supervising, controlling or otherwise managing operation of computing device 10, for example, scheduling execution of software programs or tasks or enabling software programs or other modules or units to communicate. Operating system 3 may be a commercial operating system. It will be noted that an operating system 3 may be an optional component, e.g., in some embodiments, a system may include a computing device 10 that does not require or include an operating system 3.

[034] Memory 4 may be or may include, for example, a Random Access Memory (RAM), a read only memory (ROM), a Dynamic RAM (DRAM), a Synchronous DRAM (SD-RAM), a double data rate (DDR) memory chip, a Flash memory, a volatile memory, a non-volatile memory, a cache memory, a buffer, a short term memory unit, a long term memory unit, or other suitable memory units or storage units. Memory 4 may be or may include a plurality of, possibly different memory units. Memory 4 may be a computer or processor non-transitory readable medium, or a computer non-transitory storage medium, e.g., a RAM.

[035] Executable code 5 may be any executable code, e.g., an application, a program, a process, task or script. Executable code 5 may be executed by controller 2 possibly under control of operating system 3. For example, executable code 5 may be an application that may management of program memory storage as further described herein. Although, for the sake of clarity, a single item of executable code 5 is shown in Fig. 1 , a system according to some embodiments of the invention may include a plurality of executable code segments similar to executable code 5 that may be loaded into memory 4 and cause controller 2 to carry out methods described herein.

[036] Storage system 6 may be or may include, for example, a flash memory as known in the art, a memory that is internal to, or embedded in, a micro controller or chip as known in the art, a hard disk drive, a CD-Recordable (CD-R) drive, a Blu-ray disk (BD), a universal serial bus (USB) device or other suitable removable and/or fixed storage unit. Content may be stored in storage system 6 and may be loaded from storage system 6 into memory 120 where it may be processed by controller 2. In some embodiments, some of the components shown in Fig. 1 may be omitted. For example, memory 4 may be a non-volatile memory having the storage capacity of storage system 6. Accordingly, although shown as a separate component, storage system 6 may be embedded or included in memory 4.

[037] Input devices 7 may be or may include any suitable input devices, components or systems, e.g., a detachable keyboard or keypad, a mouse and the like. Output devices 8 may include one or more (possibly detachable) displays or monitors, speakers and/or any other suitable output devices. Any applicable input/output (I/O) devices may be connected to computing device 10 as shown by blocks 7 and 8. For example, a wired or wireless network interface card (NIC), a universal serial bus (USB) device or external hard drive may be included in input devices 7 and/or output devices 8. It will be recognized that any suitable number of input devices 7 and output device 8 may be operatively connected to computing device 10 as shown by blocks 7 and 8.

[038] A system according to some embodiments of the invention may include components such as, but not limited to, a plurality of central processing units (CPU) or any other suitable multi- purpose or specific processors or controllers (e.g., controllers similar to controller 2), a plurality of input units, a plurality of output units, a plurality of memory units, and a plurality of storage units.

[039] Reference is now made to Fig. 2, which is a block diagram depicting a system 1 for management of program memory storage, according to some embodiments. System 1 may include at least one computing device 10 (e.g., element 10 of Fig. 1), configured to produce an executable instruction code, and at least one target device 20, configured to receive the produced code, and execute it by a controller or processor therein, as known in the art.

[040] For example, computing device 10 may be a desktop computer, a server computer, a smartphone a laptop and the like, and target device 20 may be an IoT device, a vehicle Electronic Control Unit (ECU) device, and the like. In some embodiments computing device 10 may also implemented as an ECU device, on condition that it has sufficient computational resources to implement embodiments of a method of management of program memory storage, as described herein.

[041] Computing device 10 and target device 20 may be communicatively connected through any type of wired or wireless communication protocol, including for example: TCP/IP, Bluetooth, WiFi, Cellular communication protocols (e.g., WCDMA, LTE, etc.), inter-vehicle communication protocols, and the like.

[042] As known in the art, target device 20 may typically include a processor or controller 210, and limited memory resources. Embodiments of system 1 may implement at least one method for:

building target device 20 software and/or firmware in computing device 10 in an executable format;

transferring the software and/or firmware to target device 20; and

storing the built software and/or firmware in a program memory storage device 220, such as a Flash memory device, a solid-state device (SSD), a Non- Volatile Random Access Memory (NVRAM) device and the like.

[043] According to some embodiments, target device 20 may include a random-access memory (RAM) device 230, that may be included in or associated with program memory storage 220 (e.g., a Flash memory device, an SSD device and the like), and may be used, for example, to sort or organize segments of program memory stored on program memory storage 220, as explained herein.

[044] As known in the art, target device 20 may be configured to transfer the executable code to a second program memory device 210- A (often referred to as an 'internal' memory device) associated with controller 210 during boot time, using a boot loader 240. Controller 210 may then execute the executable code from the internal program memory 210- A at run-time. [045] In some embodiments, at least one computing device 10 (e.g., a personal computer, a server, a laptop computer and the like) may be configured to receive as input 30 (e.g., from an external storage device, not shown) a file including software instruction code in a high-level programming language (e.g., C, C++, and the like). As known in the art, computing device 10 may build the software instruction code, to produce object code 40.

[046] Reference is now made to Fig. 3, which is a schematic block diagram, depicting an example of object code data that may be used by a system (such as system 1 in Fig. 2) for management of program memory storage, according to some embodiments. Object code 40 may include or may be formatted as one or more object files 41 (e.g., 41A, 41B and 41C). The one or more object files 41 may include a plurality of object code segments 410 (e.g., 410A, 410B and 410C) and a respective plurality of storage address fields 412 (e.g., 412A, 412B and 412C). It should be appreciated that while three object files, three code segments and three address fields are depicted in Fig. 3, any number of object files, code segments and address fields may be used.

[047] As known in the art, during an initial stage of producing an object code from a high-level instruction code, a process commonly referred to as a code building process, the plurality of object code segments may be attributed (e.g. as part of the storage address fields 412), a respective plurality of linker placeholders. The linker placeholders may be or may include for example an initial or arbitrary value. The value stored within the storage address fields 412 may be modified, during a linking stage of the build process, where the linker placeholders may be changed to a value of a storage address pointer or reference to a location where the respective object code segment is to be stored on program memory storage 220.

[048] Embodiments of the present invention may implement a method for optimally selecting at least one storage address pointer, so as to require minimal storage space on program memory storage 220 and require minimal network traffic for transferring object code 40 between computing device 10 and target device 20, as explained herein.

[049] As known in the art, the object code segments may be associated with respective one or more segments of the software instruction code. For example, specific segments of the at least one object file may be associated (e.g., by a label, a name or an identifier) with functions of software modules (e.g., software applications, drivers, kernel objects, etc.) within the software instruction code. According to some embodiments, each object code segment may be associated with an abstraction layer, including for example: a kernel layer, a driver layer and an application layer.

[050] In some embodiments, object file 41 may include a function identifier field 411 (e.g., 411A, 411B and 411C), associating one or more object code segments 410 with respective functions identifiers of functions within software modules of the software instruction code.

[051] Referring back to Fig. 2, according to some embodiments, computing device 10 may receive as input 30 instruction code in an upper- level computing language (e.g., C, C++, and the like), and may execute (e.g., on element 2 of Fig. 1) one or more software modules to process (e.g., build) instruction code 30 and produce object code 40. For example, computing device 10 may employ one or more of: (a) a preprocessing module 100, (b) a compiler module 110, (c) an assembler module 120, and (d) a linker module 130, as known in the art.

[052] It should be noted that embodiments may include any combination or subset of modules 100, 110, 120, 130. For example, computing device 10 may receive as input 30 one or more object files that may include a plurality of object code segments and a respective plurality of linker placeholders in storage address fields 412. Computing device 10 may consequently only employ linker module 130 to produce object code 40, with program memory address pointers in storage address fields 412, as elaborated herein.

[053] As known in the art, program memory storage 220 may include a plurality of storage blocks. For example, program memory storage 220 may be a Flash device, including a plurality of blocks that are the minimal erasable entities within the flash device, where each block includes a plurality of programmable pages.

[054] According to some embodiments, computing device 10 may receive storage block information 31 relating to program memory storage 220. Storage block information 31 may include for example: the number of storage blocks and the size of storage blocks within program memory storage 220.

[055] Computing device 10 may receive (e.g. from a user, via element 7 of Fig. 1) additional storage block information 31, including a block utilization limit parameter. For example, a user may dictate that one or more blocks of program memory storage 220 may be utilized (e.g., store program data therein) up to a predefined limit (e.g., up to 60% of the block size). [056] Computing device 10 may be configured to sparsely stack or accumulate object code segments to produce two or more libraries 415 (e.g., elements 415A and 415B of Fig. 3) according to the storage block information.

[057] The term 'sparse' may be used herein in relation to stacking of object code segments to refer to the location of the object code segments in a program memory storage device. For example, object code segments may be allocated non- sequential storage locations on program memory storage 220 (e.g., in order to reserve space for future additions or modifications of the object code).

[058] For example, assume that:

the size of each block in program memory storage 220 is 100 kB (kilo-Bytes);

the utilization limit parameter is set (e.g., by a user configuration) to 60%; and the storage size of object code segments 410A - 410D are 39, 20, 9 and 49 kB respectively.

[059] From the provided data, it may be derived that:

the utilization limit of storage blocks is 60% of lOOkB, i.e., 60 kB;

the cumulative size of object code segments 41 OA and 410B is 59 kB;

the cumulative size of object code segments 410C and 410D is 58 kB.

[060] Consequently, computing device 10 may:

stack object code segments 410A and 410B, to produce a first library 415A, the size of which (59 kB) is beneath the utilization limit of storage blocks; and

stack object code segments 410C and 410D, to produce a second library 415B, the size of which (58 kB) is also beneath the utilization limit of storage blocks.

[061] Pertaining to the example above, embodiments of the invention may stack the object code segments in a sparse manner so that library 415A may be allocated storage space on a first block of storage 220, and may occupy only 60% of the first storage block, and library 415B may be allocated storage space on a second, possibly consecutive block of storage 220, and may occupy only 60% of that block.

[062] Linker 130 may replace the plurality of linker placeholders with actual addresses of sections of program memory according to the stacking of object code segments. [063] Pertaining to the same example, linker 130 may replace the initial content of storage address fields 412A - 412D to address pointers, where:

412A and 412B would point to addresses of pages within the first storage block of storage 220; and

412C and 412D would point to addresses of pages within the second storage block of storage 220.

[064] According to some embodiments, computing device 10 may receive (e.g., from a user via element 7 of Fig. 1) and attribute specific block utilization limit parameters per each software module. For example, a first application that may be prone to future fixes may be attributed a first block utilization limit value, and a second application that may be less prone to future fixes may be attributed a second block utilization limit value that is higher than the first block utilization limit value. Computing device 10 may consequently stack the object code segments according to the attributed block utilization limit. Pertaining to the same example, libraries pertaining to the first application may be stacked, and later stored on storage 220 more sparsely (e.g., with greater gaps between libraries) than libraries pertaining to the second application.

[065] Computing device 10 may transmit (e.g., via a wired or wireless communication network) object code 40, that may include a plurality of object code segments, sparsely stacked into libraries (e.g., 415A, 415B) as explained above, to target device 20.

[066] Target device 20 may sparsely store the plurality of object code segments on the storage device according to the actual addresses allocated thereto. Pertaining to the same example, controller 210 may configure program memory storage 220 to store the content of library 415A according to storage address pointers 412A and 412B (e.g., within the first storage block) and store the content of library 415B according to storage address pointers 412C and 412D (e.g., within the second storage block).

[067] The content of libraries 415A and 415B may be stored sparsely, e.g., in non-contiguous addresses of program memory storage 220, according to the storage address pointers. For example, library 415 A may occupy the first 60kB of the first storage block, and library 415B may occupy the first 60kB of the second storage block, thus forming a gap between the two stored instances. [068] As explained above, the plurality of object code segments 410 may be associated with respective one or more functions of software modules via function identifiers 411. In some embodiments, the sparse stacking of object code segments, and consequent storage thereof on program memory storage 220 may include selection of object code segments according to the association of the object code segments with the respective functions of software modules.

[069] For example, computing device 10 may identify or determine that two or more functions are related (e.g., when a first function includes or calls a second function), as explained herein. Linker 130 may consequently select the two or more object code segments associated with the related functions to aggregate them into a library. Target device may subsequently localize the storage of the object code segments associated with the related functions (e.g., store the related object code segments in a single storage block). This compartmentation of executable code may facilitate an update of software in a manner that is optimal in terms of: (a) the number of changes that may be required on the data stored on program memory storage 220, and (b) the amount of data that may need to be transferred from computing device 10 to target device 20 in case of such a software update.

[070] Reference is made to Fig. 4 which is a block diagram, depicting an example of an implementation of a system for management of program memory storage as part of an inter- vehicle network constellation, according to some embodiments.

[071] In some embodiments, a system such as system 1 in Fig. 2 may be embedded into or implemented as an inter- vehicle network 200 or bus. For example, system 1 may include one or more ECUs as target devices 20 (e.g., 20A and 20B), and may optimize communication on the inter- vehicle network 200.

[072] In some embodiments, inter-vehicle network 200 may include a master ECU 211 including a processor (e.g., such as element 2 of Fig. 1) in communication with other ECU components of inter-vehicle network 200 (where communication is indicated with arrows in Fig. 4). For example, master ECU 211 may communicate with one or more slave ECU modules (e.g., 20A, 20B) as known in the art, and with a communication ECU 212.

[073] It should be appreciated that system 1 may allow optimization of various attributes of data transfer, such as optimization of memory allocation as well as optimization of operating time (e.g., reduction of downtime) for the data to be transferred and/or uploaded data, for instance data for software/firmware updates.

[074] In some embodiments, processor 211 may be coupled to at least one ECU 20 (e.g., 20A and 20B) and may analyze operations of ECUs coupled thereto. It should be noted that each of processor 211 and ECUs 20 coupled thereto may be considered as a node of the inter-vehicle network 200. In some embodiments, communication between nodes of inter-vehicle network 200 may be carried out at least partially with wireless communication (e.g., via Bluetooth).

[075] In some embodiments, inter-vehicle network 200 may include a communication ECU 212 configured to allow wired or wireless communication within inter-vehicle network 200 and/or communication with external devices. For example, communication ECU 212 may enable communication to computing device 10, as elaborated in Fig. 2. In another example, communication ECU 212 may enable a navigation system ECU to communicate with satellites and/or to receive messages (e.g., a time stamp) from external sources. In some embodiments, communication ECU 212 may be implemented on the same entity as master ECU 211.

[076] In some embodiments, master ECU 211 may be configured to perform as the computing device 10 of Fig. 2, and produce object code 30, as elaborated above in relation to Fig. 2, and at least one ECU device (e.g., 20 A, 20B) may perform as the target device 20 of Fig. 2, and may store the executable code on a program memory storage device (e.g., element 220 of Fig. 2), to execute the code on a respective processor (e.g., element 210 of Fig. 2) therein.

[077] Alternately, or additionally, as depicted in Fig. 4, master ECU 211 may be configured to transfer (e.g., via communication ECU 212) object code 30 from an external computing device 10 to at least one ECU device (e.g., 20A, 20B), which may in turn store the executable code on a program memory storage device (e.g., element 220 of Fig. 2), to execute the code on a respective processor (e.g., element 210 of Fig. 2) therein.

[078] In some embodiments, communication between nodes of inter-vehicle network 200 may be continuous or periodic (e.g., sending single files and/or images). According to some embodiments, all communication within inter-vehicle network 200 may be stored (e.g., on a memory unit) and processor 211 may analyze the communication history and determine that communication previously received by at least one node of inter- vehicle network 200 may be compromised. [079] According to some embodiments, at least one node of inter- vehicle network 200 may analyze and/or process data within inter- vehicle network 200. In some embodiments, at least one computing device (such as device 10, as shown in Fig. 1) may be embedded into inter-vehicle network 200 and may process data from the network to analyze data within the inter-vehicle network 200. In some embodiments, at least one computing device (such as device 10, as shown in Fig. 1) may be embedded into at least one node of inter-vehicle network 200 and process data from that node and/or from the network to analyze data within the inter- vehicle network 200.

[080] According to some embodiments, a node of the inter-vehicle network 200 may include a low-end processing chip such as controller 210 shown in Fig. 2.

[081] Reference is now made to Fig. 5 A and 5B, which are block diagrams depicting examples of utilizing a program memory device (e.g., element 220 of Fig. 2) as part of a system for management of program memory storage, according to some embodiments. In these examples, program memory storage 220 includes 10 storage blocks, each having lOOkB of memory space and the total storage space required for the object code (e.g., element 40 of Fig. 2) is 600kB.

[082] Fig. 5A depicts a 'naive', consecutive allocation scheme for the object code 40 on storage element 220, where the first six storage blocks are sequentially allocated to store object code 40. This allocation is naive, in the sense that a minor change in object code 40 may require extensive transfer of data from computing device 10 to target device 20, as well as extensive data reallocation (e.g., a plurality of program/erase cycles for storage devices 220 implemented as Flash memory devices, as known in the art).

[083] For example, assume that input 30 (e.g., an instruction code in a high-level programming language such as C) is updated to include a small change (e.g., adding a local feature to one function of a software module). Object code 40 may consequently increase in size (e.g., by lkB, to 601kB).

[084] If program memory storage 220 is a Flash device, and the additional code segment should reside according to the contiguous allocation scheme in block number 2, then block 2 will need to be re- flashed in its entirety, as no partial erasure of blocks is permitted on Flash devices.

[085] After such reprograming of block number 2, some of the code in that block will need to be moved to the consecutive block, i.e. block number 3, and so on, so that the following blocks may be similarly programmed. This process will be repeated, as depicted in Fig. 5A, all the way to block number 6. In some embodiments, the blocks '0' and T may also need to be reprogrammed, as they may include a relative reference to subsequent blocks (e.g., blocks of higher indices) that may no longer be valid.

[086] Furthermore, as target device 20 (e.g., an IoT device) is normally implemented as a low- end chip, it may be limited in storage resources. For example, target device 20 may not have enough RAM space to implement a delta algorithm as part of a software update procedure. Therefore, the content of each block of the updated object code may need to be transferred in its entirety from computing device 10 to target device 20. For example, as explained above, execution of commercially available delta algorithms (e.g., "bspatch") on a single storage block of lOOkB may require as much as lOOkB + lOOkB + 0(1) RAM space. This space may be greater than the space available on RAM 230 (e.g., 150kB). Hence every update of content of a storage block of program memory storage 220 may require a complete transfer of the content of the updated block from computing device 10 to target device 20.

[087] Additional aspects of the extensive reallocation of program memory blocks as described above may include for example:

an extended period of system down- time;

a higher probability of data error; and

elevated data network traffic.

[088] Figure 5B depicts an improved, sparse program memory allocation scheme, in which the data is allocated sparsely, e.g., in a non-contiguous manner. For example, object code 40 may be partitioned in advance according to a block utilization limit parameter. As depicted in Fig. 5B, the limit parameter may be 60%, and object code 40 may consequently be partitioned to ten parts and stored sparsely on each of blocks 0 through 9.

[089] If object code 40 is updated to include a small change that may increase its size (e.g., by lkB, to 601kB), the additional data may be written into a single block of program memory storage 220, without affecting or requiring reallocation of adjacent blocks. For example, if program memory storage 220 is implemented as a Flash device and if an additional object code segment needs to reside, according to the sparse allocation scheme, within storage block number 2, the additional object code segment may be written to vacant pages within block 2 as depicted in Fig. 5B, without affecting adjacent blocks as in the example depicted in Fig. 5A.

[090] Furthermore, as the updated block depicted in Fig. 5B (e.g., block number 2) only stores 60kB of program data (in contrast with lOOkB, as depicted in Fig. 5A), target device 20 may only require 60kB + 60kB + 0(1) of RAM 230 space to facilitate a delta algorithm such as "bspatch" as part of a program update process (in contrast with 200kB+O(l), as in the example depicted in Fig. 5A). Thus, in the sparse allocation scheme depicted in Fig. 5B, system 1 may only need to transfer lkB of new code from computing device 10 to target device 20.

[091] Accordingly, the scheme depicted in Fig. 5B provides a number of benefits over the scheme depicted in Fig. 5A during update of data storage on target device 20. These benefits include, for example:

decreased quantity of data storage in each update cycle;

decreased frequency of programming an erasure cycles;

improved longevity of storage device 220 (which is directly dependent on the number of programming cycles, as known in the art);

a decrease of transferred data over the network;

a decrease in data error probability due to smaller transfer of data; and

a decrease in down time of target device 20 due to software updates.

[092] According to some embodiments, computing device 10 may receive a fix or update to previously received input code 30. In some embodiments, this fix may be received as a second instruction code in a high-level software language (e.g., C, C++), and computing device may process or build the new input code as known in the art, to produce a respective, second object code including at least one object file. Alternately, the fix may already be received at computing device 10 (e.g., from an external source, not shown) as a second object code, including at least one object file, including at least one object code segment.

[093] Computing device 10 may apply a delta encoding algorithm on the at least one first and second object files, as known in the art, to produce a patch file. The patch file may include at least one patch object code segment. [094] Computing device 10 may transfer the at least one patch object code segment to target device 20, and processor 210 of target device 20 may store the at least one patch object code segment on a block of the program memory storage 220.

[095] As explained above, processor 210 of target device 20 may be configured execute to delta algorithm (e.g., "bspatch") as known in the art to replace the program data stored on storage 220 with the updated software, and reboot to load the updated software to program memory device 210- A and execute the updated software.

[096] Alternately, or additionally, at least one storage block (e.g., one block) of storage 220 may be dedicated to store one or more patch object code segments, and at least one storage block of storage 220 may hold an address table associating each object code segment with a respective storage address on a block of the program memory storage.

[097] Processor 210 of target device 20 may be configured, upon receiving a patch object code segment, to replace the storage address of at least one object code segment on the address table with that of the patch object code segment.

[098] Accordingly, when an updated function is called, instead of jumping to the called function address, processor 210 would get the address of the fixed or updated function within the patch- dedicated storage block from the address table and execute the updated software.

[099] In some embodiments, in order to achieve optimization of data transfer, a dedicated algorithm may be implemented on computing device 10. Such algorithm may include executable code for a linker (e.g., element 130 of Fig. 2) form partitions in the compiled code (e.g., object code 40) prior to replacing the content of storage address fields 412 (e.g., elements 412A, 412B, 412C and 412D of Fig. 3) from linker placeholders to pointers to actual storage addresses.

[0100] As known in the art, linker 130 module may typically receive output of a preprocessing module 100, a compiling module 110 and an assembly module 120. This output may be formatted as an assembly code version of the source code (e.g., as one or more object files), and may include placeholder addresses (e.g., addresses that are initialized to an arbitrary value, such as OxFFFF) instead of real storage addresses.

[0101] Linker 130 may create a single executable code 40, by finalizing the location of object code segments and replacing all the placeholders with real storage addresses. [0102] According to some embodiments, linker 130 may sparsely stack object code segments into libraries based on flash block information (e.g., as depicted in Fig. 5B). This stands in contrast to serial library stacking (e.g., as depicted in Fig. 5 A) that may be common practice in commercially available linkers.

[0103] In some conditions, a first change or update in an instruction code may impact a plurality of code segments and may induce a plurality of alterations in object code 40. For example, a change in a single function of a software module may require a change to the function's prototype or address that may, in turn, demand a change in all the instances of the function's calls that may be manifested on a plurality of storage blocks.

[0104] Embodiments may include a method of avoiding such proliferation of changes, through novel compartmentation of object code segments according to a hierarchical function call structure, as explained herein.

[0105] As known in the art, IoT devices in general and automotive devices in particular typically use bare-board implementations that may create a monolithic code image, where one is unable to discern between different software components. Partitioning or compartmenting the code according to different software modules (e.g., applications, drivers, kernel objects and the like) may not be possible under such conditions.

[0106] However, as known in the art, IoT software may typically be characterized by the following features:

the code image is normally static (or deterministic), meaning that the flow of the program may be completely determined at compilation time; and

the code is non-recursive, as required by the ISO-26262 standard and/or MISRA-C best coding practices, meaning that a function may either call a child function or end and return to its caller, but will never call one of the callers up the call graph.

[0107] Reference is now made to Fig. 6 which is a block diagram, depicting an example of a function call graph, which may be included within a system for management of program memory storage, according to some embodiments.

[0108] According to some embodiments, linker 130 may be configured to produce a function call graph including a plurality of nodes (e.g., main, fund , func2, func3, etc.). Each node may represent a specific function (e.g., main(), funcl(), func2(), func3(), etc. respectively) associated with a respective object code segment, as explained above in relation to Fig. 2. The nodes may be interconnected by a plurality of edges, each representing a call of one function (e.g., main()) to another function (e.g., funcl()).As explained above, the call graph may represent a static, non- recursive code image. The non-recursion assumption is manifested by the fact that the software flows strictly from the left hand side to the right hand side. No arrows point from right to left in Fig. 6.

[0109] According to some embodiments, linker 130 may be further configured to attribute each node of the function call graph with a size indicator, representing a storage size of the respective object code segment. For example, as depicted in Fig. 6, funcl 1 may be associated with a 50kB- large object code segment and funcl 11 may be associated with an object code segment that may consume 0.5kB of storage.

[0110] Function call graph 140 may be implemented as any appropriate data structure known in the art, including for example a linked list, a relational database and the like. Function call graph 140 may be stored in a storage device (e.g., element 4 or 6 of Fig. 1) associated with or included within computing device 10.

[0111] According to some embodiments, object code segments may be sparsely stacked into libraries according to the call graph. Selection of object code segments for stacking may include the following stages:

[0112] First, linker 130 may select a group (e.g., Groupl) of nodes including, or representing one or more object code segments (e.g., object code segments respective to functions: fund i, funcl 11, funcl 12, funcl 13 and funcl 121). The nodes may be related along branches of the function call graph (e.g., derive from a common calling function, such as funcl in the example of Groupl).

[0113] The cumulative value of the one or more object code segments' size indicators of the group may be limited so as not to surpass the block utilization limit. Pertaining to the aforementioned example, where the block utilization limit was 60% and the block size is lOOkB, this limit is set to 60kB. Therefore, the cumulative sum of object code segment sizes in each group may be limited to 60kB. As shown in Fig. 6, each of groups Groupl, Group2 and Group3 comply with this limitation. [0114] Linker 130 may sparsely stack the object code segments of the selected group (e.g., Groupl) to produce a library, as elaborated above in relation to Fig. 2.

[0115] Linker 130 may repeat the above steps of selecting groups of object code segments and sparsely stacking the them to produce libraries, until all object code segments of the at least one first object file are stacked in libraries. Computing device 10 may consequently produce object code 40 according to the sparse stacking of libraries and target device 20 may store the produced object code 40 on program memory storage 220 as explained above.

[0116] As known in the art, compiled object code normally includes an indication of storage size per each object code segment. For example, object files or assembly files normally include an indication of the storage size (e.g., size, start and/or end location, and the like) required for each function of the source code. According to some embodiments, linker 130 may calculate or extract from the object code the storage size required for each object code segment. Linker 130 may attribute each node of the function call graph a size indicator, representing the storage size of the respective object code segment.

[0117] In some embodiments, linker 130 may create call graph 140 with code size of the called function, as shown in Fig. 6. Once the code size is calculated for each function, these functions may be grouped to groups around the target number for the block, and distant to each other as possible. In the abovementioned example, the block should be around 60kB (as we target 60% fullness), and a total of ~53kB is grouped in Fig. 3B (shown at the uppermost group).

[0118] In some embodiments, such grouping may be achieved by scanning the call tree bottom- up, starting from functions that do not call any other function (e.g., func3121) up the call stack (e.g., up to func3), and constructing a cluster that may fit into the predetermined (or designated) size (e.g., 60kB, as in the aforementioned example). It should be noted that such a method may maximize the chance that upon updating code with a fix, only a specific block may need to be replaced or updated. Thus, resulting in memory allocation at the processing chip with increased likelihood of transferring less data (e.g., reducing redundancy).

[0119] Reference is made to Fig. 7 which is a flow diagram, depicting a method of management of program memory storage, according to some embodiments. In some embodiments, the method of management of program memory storage may be performed by computing device 10 (e.g., element 10 of Fig. 1) or by any other computation device that may be associated with a target device (e.g., element 20 of Fig. 2) and/or embedded or included within a network of IoT devices (e.g., an inter-vehicle network 200, as depicted in Fig. 4).

[0120] As shown in step S1005, computing device 10 may receive (e.g., by a user, via input device 7 of Fig. 1) storage block information of a program memory storage device (e.g., element 220 of Fig. 2). The storage block information may include at least one of: storage block size of storage 220 and block utilization limit of program memory storage 220.

[0121] as shown in step S1010, computing device 10 may receive (e.g., via input device 7) at least one object file including a plurality of object code segments and a respective plurality of linker placeholders. Additionally, or alternatively, computing device 10 may receive at least one file of instruction code in a high-level computing language (e.g., C, C++ and the like), and process or build the instruction code to obtain the at least one object file.

[0122] As shown in step S1015, computing device 10 may sparsely stack the object code segments to produce two or more libraries according to the storage block information. For example, computing device 10 may accumulate object code segments to produce two or more libraries 415 (e.g., elements 415A and 415B of Fig. 3) according to the storage block information, and allocate sparse (e.g., non-contiguous) memory space for the stacked libraries according to the predefined block utilization limit, as depicted in Fig. 5B.

[0123] As shown in step S1020, computing device 10 may replace the plurality of linker placeholders with actual addresses of sections of program memory according to the stacking of object code segments. For example, computing device 10 may replace at least one linker placeholder in a storage address field (e.g., elements 412A, 412B, 412C and 412D of Fig. 3) of an object file 41 (e.g., 41A, 41B, 41C), with a pointer or reference to a memory address of storage 220.

[0124] As shown in step S 1025, computing device 10 may store the plurality of object code segments on the storage device according to the actual addresses. For example, computing device 10 may transmit (e.g., over a wired or wireless network) object code (e.g., element 40 of Fig. 2 and Fig. 3) to at least one target device 20. A processor or controller (e.g., element 210) of the at least one target device 20 may receive the transmitted object code 40 and may store the content of object code 40 on storage 220 according to the address pointers in the storage address fields 412 therein. [0125] Reference is made to Fig. 8 which is a flow diagram, depicting a method of management of program memory storage on a storage device, according to some embodiments.

[0126] As shown in step S2005, computing device 10 may receive (e.g., by a user, via input device 7 of Fig. 1) storage block information of a program memory storage device (e.g., element 220 of Fig. 2). The storage block information may include at least one of: storage block size of storage 220 and block utilization limit of program memory storage 220.

[0127] As shown in step S2010, computing device 10 may receive at least one instruction code file that may be formatted in a high-level programming language such as C or C++. Computing device 10 may analyze at least one instruction code file, to produce a function call graph, as depicted in Fig. 6.

[0128] As shown in step S2015, computing device 10 may compile the at least one instruction code file, as known in the art, to produce at least one object file comprising a plurality of object code segments and a respective plurality of linker placeholders, as depicted in Fig. 3.

[0129] As shown in step S2020, computing device 10 may sparsely stack the object code segments to produce two or more libraries according to the storage block information and the function call graph, as explained above in relation to Fig. 6.

[0130] As shown in step S2025, computing device 10 may replace the plurality of linker placeholders with actual addresses of sections of program memory storage 220 or pointers thereto (e.g., in storage address fields 412 of object code 40, as explained above in relation to Fig. 3) according to the stacking of object code segments. Computing device 10 may transmit the updated object code 40 to at least one target device 20.

[0131] As shown in step S2030, target device 20 may sparsely store the plurality of object code segments on program memory storage 220 according to the actual addresses in the address fields 412 of object code 40.

[0132] According to some embodiments, at least one storage block of program memory storage 220 may be predefined for patching future fixes. For example, embodiments may include aggregating all of the fixes (which are assumed to be an order of magnitude smaller than the relevant code) together in a dedicated storage block, and use an addressing table, to access these fixes. [0133] In some embodiments, when a function is called, instead of jumping to the called function address, the actual address may be received from a different hard coded location in the patch block, and the addressing table may be at the dedicated block to point at the right function. When such a function is added or replaced, it may be added to the patch block (e.g., block '9'), and the pointer to it may be updated in the addressing table. For example, the memory map may be as shown in table 1 below:

Table 1 [0134] After a fix is added, block '9' may include 1%+1 % memory allocation, where the address of block '9' may correspond to the patched function. Thus, the patched function may be executed so there is no need to delete the original function.

[0135] In some embodiments, all the functions may be collected (e.g., in the preprocessing stage) and a new source file with a table of the functions may be created, so as to replace the source code function calls with references to the new table.

[0136] According to some embodiments, for a given code the preprocessor may create and initialize a function table. The new file with the function table may then be located in block '9' using available linker programs (or the linker as described above). In some embodiments, a dedicated algorithm may indicate differences in the code, where the detected changed function may be copied to the function table file, such that the pointer in the table may be updated. Finally, the new code and function table may be burned to block '9'.

[0137] According to some embodiments, some chipsets may include hardware that may be used with similar methods, but without any real-time implication (e.g., the hardware breakpoint mechanism). This is a mechanism that in hardware is constantly comparing the program counter in a chip to a configurable constant address, and once that address is reached, instead of fetching the next opcode from that address it may jump to the breakpoint or patch address. In some embodiments, all the fixes in a patch block may be maintained and code may be added in the boot that checks to see if it has a patch therein. In case a patch is present, the algorithm may configure the patch address in this hardware module and then the chip may execute the patched code instead of the original code in run time. Since the code flow of the program is known in advance (e.g., static code), then the next patch that needs to be run is known and the algorithm may configure the hardware accordingly.

[0138] In some embodiments, such an algorithm may achieve zero real time impact while only needing to transfer and burn the patch block.

[0139] In some embodiments, when an application such as "AutoSAR" based application is compiled, a monolithic image that contains both lower layer and application layer may be received in a single binary blob. The application layer may include software components, which are the most likely to be updated in general. Thus, in order to maximize the chance of updating a small portion of code, code compartmentalization may be applied (to get easier updates of the software components). It should be noted that while "AutoSAR" based application is described above, any type of similar application may also be applied. In some embodiments, the software components may be separated from the lower layer as depicted in table 2 herein:

2 100% Lower layer code

1 100% Lower layer code

0 100% Lower layer code

Table 2

[0140] According to some embodiments, updated ECU may maintain two copies of the its software, one that it is running from, and another to update (e.g., for updating while executing), such that the normal ECU functionality may be kept, while it overwrites the second copy of its software. In some embodiments, the delta algorithm (e.g., "bspatch") may be modified accordingly. Namely, instead of keeping the old software and changes in the RAM, and then building the new software in the RAM (requiring n + m + 0(1) memory), the old software that is available may be utilized. All the changes in the RAM may be kept, but instead of keeping the old and new software, only the next block to burn in the RAM may be kept. In order to build it the required information is available, the changes in the RAM and the old software (read only) in the flash, so that the memory requirements go down to 0(1) + max(flash block size), which is smaller than the previously needed memory footprint, thus enabling more ECUs to run a delta algorithm.

[0141] It should be noted that most of the abovementioned methods require linker level interference in the binary creation process, where the linker decides where to place the compiled code and its different sections and replaces the addressing placeholders accordingly. In some embodiments, this might be realized as a plugin to an existing linker and/or a new linker and/or as a separate linker pass either before or after the normal linking.

[0142] It should be noted that such implementation method may include at least one of the following advantages: predictable since for a specific update length based on the number of blocks planned to update there is no need to "guess" compression performance, works in tandem with other ("classic") delta technologies for per-block compression and easy integration with existing processes where there is no need for a dedicated "back-end" for on-the-fly generation of delta updates. [0143] Unless explicitly stated, the method embodiments described herein are not constrained to a particular order in time or chronological sequence. Additionally, some of the described method elements may be skipped, or they may be repeated, during a sequence of operations of a method.

[0144] Various embodiments have been presented. Each of these embodiments may of course include features from other embodiments presented, and embodiments not specifically described may include various features described herein.

Claims

1. A method of managing program memory on a storage device, the method comprising:

receiving storage block information, comprising at least one of: storage block size of a storage device and block utilization limit of the storage device;

receiving at least one first object file comprising a plurality of object code segments and a respective plurality of linker placeholders;

storing the plurality of object code segments on the storage device according to the actual addresses.

2. The method of claim 1 , wherein the plurality of object code segments is associated with respective one or more functions of software modules, and wherein sparsely stacking of object code segments comprises selection of object code segments according to the association of the object code segments with the respective functions of software modules.

3. The method of claim 2, further comprising:

attributing a block utilization limit to each software module; and

4. The method of claim 2, further comprising:

attributing each node of the function call graph with a size indicator, representing a storage size of the respective object code segment.

5. The method of claim 4, wherein selection of object code segments for stacking comprises: a. selecting a group comprising one or more object code segments that are related along branches of the function call graph, such that the cumulative value of the one or more object code segments' size indicator does not surpass the block utilization limit;

6. The method of claim 5, further comprising:

7. The method of claim 6, further comprising maintaining an address table associating each object code segment with a respective storage address on a block of the program memory storage, wherein storing the patch object code segment further comprises replacing the storage address of at least one object code segment on the address table with that of the patch object code segment.

8. The method of claim 2, wherein the software modules are associated with one or more abstraction layers, selected from a list comprising a kernel layer, a driver layer and an application layer.

9. A system for managing program memory on a storage device, the system comprising:

a first storage device;

a second, non-transitory memory device, wherein modules of instruction code are stored, and a processor associated with the second device, and configured to execute the modules of instruction code, whereupon execution of said modules of instruction code, the processor is configured to perform at least one of:

receive storage block information of the first storage device, comprising at least one of: storage block size of a storage device and block utilization limit of the storage device; receive at least one first object file comprising a plurality of object code segments and a respective plurality of linker placeholders;

10. The system of claim 9, wherein each of the plurality of object code segments is associated with one or more respective functions of software modules, and wherein sparsely stacking object code segments further comprises selection, by the processor, of object code segments according to the association of the object code segments with the respective functions of software modules.

11. The system of claim 10, wherein the processor is further configured to:

attribute a block utilization limit to each software module; and

stack the object code segments according to the attributed block utilization limit.

12. The method of claim 10, wherein the processor is further configured to:

produce a function call graph comprising a plurality of nodes, each representing a specific function associated with an object code segment, and a plurality of edges, each representing a call of one function to another; and

attribute each node of the function call graph with a size indicator, representing a storage size of the respective object code segment.

13. The system of claim 12, wherein the processor is further configured to:

a. select a group comprising one or more object code segments that are related along branches of the function call graph, such that the cumulative value of the one or more object code segments' size indicator does not surpass the block utilization limit;

b. stack the group of selected object code segments to produce a library; and

c. repeat steps a and b, until all object code segments of the at least one first object file are stacked in libraries.

14. The system of claim 13, wherein the processor is further configured to:

receive at least one second object file comprising at least one object code segment;

apply a delta encoding algorithm on the at least one first and second object files to produce a patch file comprising at least one patch object code segment; and

store the at least one patch object code segment on a block of the program memory storage.

15. The system of claim 14, wherein the processor is further configured to maintain an address table associating each object code segment with its respective storage address on a block of the program memory storage, and wherein storing the patch object code segment by the processor further comprises replacing the storage address of at least one object code segment on the address table with that of the patch object code segment.

16. The system of claim 10, wherein the software modules are associated with one or more abstraction layers, selected from a list comprising a kernel layer, a driver layer and an application layer.

17. A method of managing program memory on a storage device, the method comprising:

receiving storage block information pertaining to a storage device;

analyzing at least one instruction code file, to produce a function call graph; compiling the at least one instruction code file, to produce at least one object file comprising a plurality of object code segments and a respective plurality of linker placeholders;

sparsely stacking the object code segments to produce two or more libraries according to the storage block information and the function call graph;